cdm vol1

ORACLE METHODSM

CDM STANDARDS ANDGUIDELINES LIBRARY

VOLUME 1 - REQUIREMENTSMODELING USING ORACLE

DESIGNER

Release 6.0.0February, 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 KootenContributors: Lauri Boyd, Lucas Jellema, Sandra MullerEditor: Mary SandersThe Programs (which include both the software and documentation) contain proprietaryinformation of Oracle Corporation; they are provided under a license agreement containingrestrictions on use and disclosure and are also protected by copyright, patent, and otherintellectual and industrial property laws. Reverse engineering, disassembly, ordecompilation of the Programs is prohibited.

The information contained in this document is subject to change without notice. If you findany problems in the documentation, please report them to us in writing. Oracle Corporationdoes not warrant that this document is error free. Except as may be expressly permitted inyour license agreement for these Programs, no part of these Programs may be reproduced ortransmitted 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 theprograms 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 theapplicable Oracle license agreement. Otherwise, Programs delivered subject to the FederalAcquisition Regulations are "restricted computer software" and use, duplication, anddisclosure of the Programs shall be subject to the restrictions in FAR 52.227-19, CommercialComputer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 OracleParkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, orother inherently dangerous applications. It shall be the licensee's responsibility to take allappropriate fail-safe, backup, redundancy, and other measures to ensure the safe use ofsuch applications if the Programs are used for such purposes, and Oracle Corporationdisclaims 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 registeredtrademarks of Oracle Corporation, Redwood City, California.

AIM Advantage, CDM Advantage, EMM Advantage, PJM Advantage, Oracle CooperativeApplications, Oracle Financials, Oracle Alert, Oracle Manufacturing, Oracle Inventory,Oracle Bills of Material, Oracle Engineering, Oracle Capacity, Oracle Commissions, OracleMaster Scheduling, Oracle MRP, Oracle Work in Process, Oracle General Ledger, OracleAssets, Oracle Order Entry, Oracle Cost Management, Oracle Payables, Oracle Receivables,Oracle Personnel, Oracle Payroll, Oracle Purchasing, Oracle Quality, Oracle Sales andMarketing, Oracle Service, and Application Object Library are trademarks of OracleCorporation, Redwood City, California.

Oracle is a registered trademark, and Oracle Method is a service mark of OracleCorporation. Microsoft and MS-DOS are registered trademarks and Windows, Word forWindows, PowerPoint, Excel, and Microsoft Project are trademarks of MicrosoftCorporation. Visio is a trademark of Visio Corporation. Project Workbench and ProjectBridge Modeler are registered trademarks of Applied Business Technology. All othercompany or product names mentioned are used for identification purposes only and may betrademarks of their respective owners.

Oracle Method Contents i

Contents

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

C H A P T E R 1 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-4Entity Relationship Modeling............................................................ 1-5Function Modeling ............................................................................. 1-6Business Rule Modeling ..................................................................... 1-6Prototyping ......................................................................................... 1-7Dataflow Diagramming ..................................................................... 1-7Audience ............................................................................................. 1-7

Oracle Designer Road Map to Requirements Modeling ........................ 1-8

Business Process Modeling (RD.010) .............................................. 1-11System Process Modeling (RD.100)................................................. 1-13Entity Relationship Modeling (RD.040, RD.060, RD.080).............. 1-14Function Modeling and ChangeEvent Rules (RD.030, RD.070, RD.090) ........................................... 1-15Authorization Rules (TA.090).......................................................... 1-17

C H A P T E R 2 Process Modeling ..................................................................................... 2-1

Related CDM Tasks................................................................................... 2-2

What is Process Modeling?....................................................................... 2-3

Benefits of Process Modeling............................................................. 2-4

ii Contents Requirements Modeling using Oracle Designer

The Business Process Model.............................................................. 2-5The System Process Model ................................................................ 2-6Overview of Process-Oriented Development .................................. 2-7Oracle Designer Support.................................................................... 2-9

Modeling the Business Context.............................................................. 2-12

Business Area.................................................................................... 2-12Defining Business Objectives and Primary Processes ................... 2-13Elements of the Context Process Diagram ..................................... 2-14Using Oracle Designer to Construct theContext Process Diagram................................................................. 2-17

Modeling Business Processes ................................................................. 2-24

Modeling Primary Processes ........................................................... 2-24Using Oracle Designer to Document Business Processes ............. 2-36Modeling Support Processes ........................................................... 2-45Constructing the Business Process Model...................................... 2-49Other Process Modeling Concepts.................................................. 2-51

Process Models and Function Hierarchy Models................................. 2-53

Functions and Processes .................................................................. 2-55Building and Using Function Hierarchieswith Oracle Designer........................................................................ 2-56Process versus Function for Project Scoping.................................. 2-61

The System Process Model ..................................................................... 2-63

Developing the System Process Model........................................... 2-64Transition from Analysis to Design ................................................ 2-65Business Process Modeling versusSystem Process Modeling ................................................................ 2-67

Verifying the Process Model .................................................................. 2-68

Business Area Comparisons ............................................................ 2-68Process Integration within the Business Area................................ 2-68Processes and Function Areas ......................................................... 2-69Process Steps and Elementary Business Functions........................ 2-69

Some Concluding Remarks .................................................................... 2-70

C H A P T E R 3 Business Rule Modeling ......................................................................... 3-1


Business Rule Classification Scheme ....................................................... 3-4

Oracle Method Contents iii

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

Attribute Rules.................................................................................... 3-9Tuple Rules (TPL) ............................................................................. 3-13Entity Rules ....................................................................................... 3-15Inter-Entity Rules.............................................................................. 3-17Additional Remarks ......................................................................... 3-21

Dynamic Data Constraint Rules............................................................. 3-22

Create Rules (CRE) ........................................................................... 3-22Update Rules..................................................................................... 3-23Modify Rules (MOD)........................................................................ 3-24Delete Rules....................................................................................... 3-25

Change Event Rules with DML.............................................................. 3-27

Default Rules (DFT).......................................................................... 3-27Other Change Event Rules (CEV) ................................................... 3-28

Change Event Rules without DML (CEW)............................................ 3-30

Authorization Rules (AUT) .................................................................... 3-31

Function Access Rules...................................................................... 3-32Vertical Data Access Rules Authorization...................................... 3-33Horizontal Data Access Rules ......................................................... 3-34

Recording a Business Rule as a Function .............................................. 3-35

Organizing Rules .............................................................................. 3-36Rule-Triggering Events .................................................................... 3-40What to Record ................................................................................. 3-43Presentation to the Business Community....................................... 3-46

The Process of Business Rule Modeling ................................................ 3-48

C H A P T E R 4 Entity Relationship Modeling ................................................................ 4-1


The Entity Relationship Model................................................................. 4-3

Business Data Modeling versus System Data Modeling................. 4-3Client Involvement ............................................................................. 4-4Cross-Checking with Function or Process Model............................ 4-5

Entities........................................................................................................ 4-6

Recognizing Entities ........................................................................... 4-6Naming Entities .................................................................................. 4-7

iv Contents Requirements Modeling using Oracle Designer

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

Attributes ................................................................................................. 4-11

Unique Identifier .............................................................................. 4-11Attributes and Relationships ........................................................... 4-12

Relationships............................................................................................ 4-13

Optionality and Degree.................................................................... 4-13Naming Relationship Ends .............................................................. 4-14Hierarchical Relationships............................................................... 4-15

Subtypes and Supertypes ....................................................................... 4-17

Naming of Subtypes......................................................................... 4-18Supertypes......................................................................................... 4-18Implied Subtypes.............................................................................. 4-19Arcs and Subtypes............................................................................ 4-19Almost Subtypes............................................................................... 4-19

ER Diagrams............................................................................................ 4-23

Knowing Where to Start .................................................................. 4-23Testing the Data Model.................................................................... 4-23Merging Structures........................................................................... 4-24Cleaning Up ...................................................................................... 4-24Knowing When to Stop.................................................................... 4-24Verifying the Data Model ................................................................ 4-25

C H A P T E R 5 Function Modeling................................................................................... 5-1


Overview of Function Modeling.............................................................. 5-3

Business Function Modeling.............................................................. 5-3System Function Modeling ................................................................ 5-3Business versus System Function Modeling .................................... 5-4Cross-Checking with the Data Model............................................... 5-5

Function Hierarchy ................................................................................... 5-6

What a Function Hierarchy Does Not Do ........................................ 5-6Software Packages .............................................................................. 5-9Where to Start ..................................................................................... 5-9Where to Stop ..................................................................................... 5-9Top-Down versus Bottom-Up......................................................... 5-10

Elementary Functions and Non-Decomposed Functions .................... 5-11

Oracle Method Contents v

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-18Lower Levels in the Hierarchy ........................................................ 5-18Lowest Level in the Hierarchy ........................................................ 5-18

Some Concluding Remarks..................................................................... 5-19

C H A P T E R 6 Prototyping................................................................................................ 6-1


Approach to Prototyping.......................................................................... 6-3

General Guidelines ............................................................................. 6-3Goals of Prototyping During Requirements Modeling ................... 6-3Risks of Prototyping ........................................................................... 6-4Conducting Prototype Sessions......................................................... 6-5

Prototyping Using Oracle Designer ......................................................... 6-7

Managing Design Objects .................................................................. 6-7

Oracle Method Readers Comment Form vii

Send Us Your Comments

CDM Standards and Guidelines LibraryVolume 1 - Requirements Modeling using Oracle Designer,Release 6.6.0

Oracle Corporation welcomes your comments and suggestions on thequality and usefulness of this publication. Your input is an importantpart 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). Youcan send comments to us in the following ways:

iDevelopment Center of ExcellenceOracle CorporationRijnzathe 63454 PV De MeernThe Netherlandsemail: [email protected]

Oracle Method Preface ix

Preface

his manual, Requirements Modeling using Oracle Designer, providesguidance 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) ofOracles Custom Development Method (CDM).

The Standards and Guidelines Library consists of a series of manualsthat help you and your organization to deliver quality Oracle solutions.

This manual, the SGL volumes, the CDM manuals and the CustomDevelopment Method itself, are part of Oracle MethodSM -- Oraclesintegrated approach to solution delivery. For more information onCDM and Oracle Method, refer to CDM Quick Tour..

T

x Preface Requirements Modeling using Oracle Designer

Positioning

The SGL manuals are positioned between the CDM Classic and CDMFast Track Process and Task References and the product-oriented Oracletools manuals. The SGL manuals continue in more detail where theCDM Process and Task Reference ends, and through references they forman entry into the Oracle tools manuals. This section describes therelationship 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 followingvolumes:

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 focuson modeling, designing, and generating multi-tier web applicationsusing Oracle Designer. The concept of modeling business rules that isintroduced in this manual is used and carried forward during designand generation.

Volume 3 - Building Systems using Oracle8 Programming Tools covers theother Oracle8 programming tools, such as, SQL, PL/SQL, and SQL*Plusthat can be used together with Oracle Designer and Oracle Developer.

Volume 4 - CDM Standards includes a list of detailed and numberedstandards and guidelines per deliverable of CDM Classic and CDM FastTrack.

Oracle Method Preface xi

Relationship to Oracle CDM Classic and CDM Fast Track

Oracles Custom Development Method (CDM) defines a set oforganized and flexible process steps that guide all involved personnelthrough the Custom Development process. CDM Classic is the naturalsuccessor of CASE Method and CDM Fast Track is the natural successorof CASE Method Fast Track.

CDM Classic and CDM Fast Track are both deliverable-based. Everytask produces one clearly defined deliverable. This manual and theother SGL manuals provide standards and guidelines on the best way toproduce these deliverables, assuming the Oracle tools are used tomodel, design, and build the application system.

Each chapter in this manual contains a reference to all related CDMClassic and CDM Fast Track tasks that benefit from the information inthat chapter.

Relationship to Other Methods

Where a method other than Oracle CDM Classic or Fast Track is to beused for a project, the project manager should conduct a mapping ofCDM tasks and deliverables to the tasks and deliverables of the othermethod. This ensures that the method to be employed for a particularproject covers the requirements of the project.

As long as Oracle Designer is used, this manual provides valuableguidelines 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 andreferences, but also include training tutorials and other specialist advice.However, these manuals do not relate the product to a projectdevelopment effort and do not take into account actual field experience.The SGL manuals are based on best practices of Oracle consultancyworld wide and provide proven standards and guidelines with aclearly-defined link to the tasks and deliverables of Oracle CDM Classicand CDM Fast Track.

The Oracle SGL manuals concentrate on the quality issues thatdevelopers and managers encounter within the project life-cycle and donot repeat advice contained in the Oracle product manuals.

xii Preface Requirements Modeling using Oracle Designer

Audience

This manual is written for business and system analysts, systemdesigners and developers, managers, and service groups that areinvolved within the life-cycle of system development andimplementation. This includes project managers and support staff ofOracle Corporation, business partners, and customers.

How This Manual is Organized

This manual contains guidelines for performing systems design andgeneration, describing techniques, and referencing Oracle CDM tasks.This SGL manual should be used in conjunction with Volume 4 - CDMStandard). The manuals are organized as follows:

Volume 1 - Guidelines

Volume 1 contains the guidelines. The guidelines provide advice andsuggestions for completing CDM tasks. The guidelines are notmandatory, but offer proven techniques and alternatives for taskcompletion. Guidelines alone are insufficient to ensure that a qualityproduct is produced, but can contribute substantially to the creation ofquality products.

Volume 4 - Standards

Volume 4 contains the standards. The standards impose a specificworking method. They are unambiguous and measurable. They allowyou, to a certain extent, to objectively assess the quality of the CDMClassic and Fast Track deliverables involved. Standards are defined at adetailed level so that all staff within a project or organization can followthe standards, easing conflict and enhancing the maintainability ofsystems. To allow for reference of the standards in this document, eachdescription of a standard is provided with a unique identificationnumber, for example, OMS-00001 (OMS stands for Oracle MethodStandard).

If an OMS standard number is underscored, this means that thestandard concerned is automatically checked by one of the utilities ofHeadstart Oracle Designer. Refer to Appendix F, Headstart OracleDesigner, in Volume 2, for more information on how to obtain theseAPI-based utilities.

Oracle Method Preface xiii

How to Use This Manual

For the guidelines of this manual to be of value, you should have aworking knowledge of Oracle Designer. Also, this manual should beused in conjunction with the CDM Classic Process and Task Reference andthe CDM Fast Track Process and Task Reference. It is the design andgeneration tasks and deliverables of these references that benefit fromthe standards and guidelines in this manual.

Before starting on systems design, carefully read the guideline chaptersin this volume to familiarize yourself with the proper use of thetechniques, and to be aware of any special cases or pitfalls.

When you record the modeling results in Oracle Designer, use therelated standards chapters in Volume 4 to check your work. Refer backto the guidelines chapters for assistance when confronted with choicesnot covered by the standards.

Oracle Services recommends that users of this manual, or anySGL/CDM manual, or CDM Classic or CDM Fast Track, take advantageof CDM training courses provided by Oracles Education Services. Inaddition to manuals and training, Oracle Consulting also providesexperienced CDM consultants and automated work management tools,customized for CDM.

xiv Preface Requirements Modeling using Oracle Designer

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, objectnames, 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, especiallyto illustrate a point with an example.

Bold Text

Bold text is designed to attract special attention to importantinformation.

Capitalization

Names of tasks, deliverables, process and phases are always give titlecapitals. For example, Design Audit Facilities task, System Data Modeldeliverable, Technical Architecture process and Build phase.

Abbreviations and Acronyms

Occasionally, it is necessary to use abbreviations and acronyms whenadequate space is not available. The Glossary lists meanings of allacronyms 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 bwhere a.deptno = b.deptno

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

ORA-00054: Resource busy and acquire with NOWAITspecified

Oracle Method Preface xv

Suggestions

We provide you with helpful suggestions throughout the handbook tohelp you get the most out of the method. We highlight thesesuggestions with an illuminated light bulb. Here is an example of asuggestion:

Suggestion: Verify your backup and recovery plan with yourhardware and software vendors.

Attention

We sometimes highlight especially important information orconsiderations to save you time or simplify the task at hand. We marksuch information with an attention graphic, as follows:

Attention: Since project team training occurs simultaneouslywith this task, some recommendations (or decisions) fromtraining may be implemented in the mapping environment.In this case, these training inputs become predecessors to thistask.

Warning

Considerations that can have a serious impact on your project arehighlighted by a warning graphic. Read each warning message anddetermine if it applies to your project. Here is an example:

Warning: Any time you insert data directly into OracleApplication tables, you run the risk of corrupting thedatabase. Oracle strongly discourages inserting data directlyinto Oracle tables that are not designed as an Open Interface.

For More Information

Throughout the handbook we alert you to additional information youmay want to review. This may be a task section, appendix, or referencemanual. We highlight these references with an easy-to-notice graphic.Here is an example:

Reference: For more information about content for thedesign presentation, review the Critical Success Factors, page3-7.

xvi Preface Requirements Modeling using Oracle Designer

Web Site

Information available on the World Wide Web is indicated by a Websymbol and an appropriate Web address. Here is an example:

Web Site: Pure Atria Corporations Home Page on theWorld 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 withan easy-to-notice graphic. Here is an example:

Difference: The optimizer of the Oracle7 Server under thecost-based approach will consider the location of data whenestimating the cost of accessing it.

Tools

When there are specific Oracle tools that can be used to automate thesystems design and generation process, we highlight these referenceswith an easy-to-notice graphic. Here is an example:

DataSchema

Tools: Data Diagrammer; Edit Table Table, Column Defnand Constraints tabsheets;

Oracle Method Preface xvii

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 (thisbook)

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 inthe CDM Quick Tour.

You may also refer to the following Project Management Method (PJM)suite of reference books:

PJM Method Handbook

PJM Process and Task Reference

Oracle Method Introduction to Requirements Modeling 1 - 1

C H A P T E R

1 Introduction to Requirements

Modeling

his chapter gives a general introduction to requirements modeling.It discusses the following topics:

the goal of requirements modeling

the various requirements modeling techniques available withinCustom Development Method

a road map for using Oracle Designer for requirementsmodeling

T

1 - 2 Introduction to Requirements Modeling Requirements Modeling using Oracle Designer

Goal of Requirements Modeling

Traditionally, we used to distinguish between Analysis and Design ofan 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 haveproperly understood what is needed is to show the users how we willsatisfy their needs. In addition, the separate roles of system analyst andsystem designer are more and more performed by the same people. Weshould not force these people to only describe the What, if theyalready have a clear picture of the How in their minds and not allowthem to write it down!

Modern project approaches, such as Fast Track and prototypingtechniques, prosper because of this knowledge. This knowledge shouldalso not be ignored in a waterfall-like project approach.

Types of Modeling

Oracles Custom Development Method (CDM), be it the classic or thefast track approach, carries forward the above principle by identifyingtwo levels of requirements modeling:

business modeling

system modeling

Business Modeling

Business models describe the informational and functional requirementsnecessary to meet the defined business objectives. The scope ofinvestigation is a business area, focus is on what the business has to doto meet its objectives. There is no distinction between manual functionsand functions that need to be supported by the computer system.Current procedures and mechanisms should only be described withinsupporting documentation (CDMs existing system deliverables).

System Modeling

System models focus on functionality that must be implemented orsupported by the computer system and identify the nature of that


support. This includes functionality concerned with the systemsinfrastructure and delivery mechanisms, for example:

data structures for the control of queues and replication of dataacross a distributed network

functions to help administer the operation of the system (errorlogging, 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 systemrequirements modeling are largely the same, you should be well awareof the differences between the two. Make sure the client has the sameperception you do concerning the scope and type of requirementsanalysis you plan to do.

Because of the similarity in techniques, the rest of this manual does notexplicitly carry forward the difference between business and systemmodeling. However, this manual provides standards and guidelines forrequirements modeling using Oracle Designer. Concepts discussed inthis manual, especially the chapter on business rules, anticipate thesubsequent use of the wizards and generators available in OracleDesigner. Therefore, they are geared towards system modeling and areless applicable to business modeling.

Having defined the difference between business modeling and systemmodeling, it is quite clear that the technology and tools that will be usedto build the system do influence system requirements modeling.

This especially holds true if multi-tier architectures are to be used. Thedistribution of your application over multiple platforms offersopportunities but also includes risks. The challenge is to take advantageof the opportunities, avoiding the risks as much as possible.


Requirements Modeling Techniques

CDM is based on a number of simple techniques that, when correctlyapplied, provide a great deal of information in an easily understoodformat. Requirements modeling is an iterative process with a numberof people discussing alternative representations. Involving clients indiscussions during model development will lead to more accuratemodels 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, showingadditional information on how the organization accomplishes specificrepetitive tasks.

This simple but powerful technique is widely known and one of themain pillars for Business Process Reengineering (BPR). With theintroduction of Oracles CDM, process modeling has become one of thethree main contributors to requirements modeling and definition.

In custom development, the primary purpose of process modeling is toscope and define business requirements for system development. Butthe real power of this technique lies in its contribution to the followingkey areas of the custom development life-cycle:

It provides an efficient tool for understanding andcommunicating business requirements.

It depicts a representation of work flow in an organization thatfacilitates definition of the application system architecture anddesign.


It provides a structure for organizing testing, design, andtraining development.

It provides a framework for determining appropriateimplementation strategies.

Process modeling is based on the view that an organization is a system.Systems exist in an environment. They receive inputs from theenvironment and produce outputs. Organizations are adaptive andpurposeful systems that respond to changes in their environment. Howwell they adapt and respond is a determinant of their success. Systemsconsist of subsystems that in turn accept inputs and produce outputs.The subsystems are the business processes of an organization. Processmodeling views processes as systems that are triggered by events,receive inputs and produce outputs.

Process flow diagrams visually represent the event response. Theyshow the process steps that are executed to produce the output that isrequired as a response to the triggering event.


Entity Relationship modeling provides a model of the informationwithin a company, and illustrates how that information is linked.

The things of importance (entities) within the business, the properties ofthose things (attributes), and how they are related (relationships) arerecorded on a diagram using soft boxes with connecting lines andresiding within the analysis repository. The entity model is one of thethree pillars of requirements modeling in CDM, along with the functionmodel and the process model.

The entity model is a very powerful communication tool for creatingcomplex models using simple conventions that can be easily explained.This technique is independent of the mechanisms used to hold thatinformation, such as paper forms or computers. As long as the businessdoes not change, the model will remain accurate.

Entity relationship modeling is covered in Chapter 4 of this manual.


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. Thestarting point and highest function of the hierarchy is the missionstatement or goal of the business. The finishing point is an elementarybusiness function such as sending out an invoice. The purpose offunction modeling is to show how that mission statement is fulfilled bythe functions performed within the business. This is a very powerfultechnique and can lead to some very fundamental questions about howan organization operates.

Function modeling is covered in Chapter 5 of this manual.

Business Rule Modeling

Traditionally, business rules have been more or less implicitly modeledduring entity relationship modeling and function modeling. Creatingan entity relationship model simply meant modeling a subset of data-oriented business rules. An elementary function used to describepresentation 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 waythat is best understood by the business community, and thus recordsbusiness rules in a way that makes it easy to communicate to thebusiness community. This does not mean that business rules should bedescribed together with the entities or business functions. Byconnecting business rules to entities and functions it is still possible topresent business rules in way they are easy to communicate. Experiencehas learned that showing the business rules that are triggered by abusiness function is the best way to present to the user.

During system requirements modeling, the impact of Internetcomputing should be taken into account. Applying a multi-tierarchitecture 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 modelingand function modeling.


By using a classification scheme of business rules, we explicitly definewhat kind of functionality is part of the application logic layer. Thedeveloper exactly knows which rules need to be implemented thatlayer. Another advantage of classifying business rules is that designestimates 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 verifyingthe correctness and completeness of your requirement models.Prototyping enables the user to see your interpretation of what isrequired in the system, and to provide feedback. Because it is tangible,the prototype also helps the client feel like they are getting somethingfor their money.

Prototyping is covered in Chapter 6 of this manual.

Dataflow Diagramming

With the introduction of process modeling, the need for dataflowdiagramming is strongly reduced. Dataflow diagrams depict processeswithin 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 specificinstance of a process flow diagram that only shows data dependencies.

Audience

As the audience for business and system models includes the futureusers, you should use natural language in all free text objects, avoidingtechnical jargon. As much as possible, use entity, attribute andrelationship names within the descriptions. If the resulting phrases areincomprehensible, your naming of entities, attributes and relationshipsis probably wrong!


Oracle Designer Road Map to Requirements Modeling

The various modeling techniques discussed in the previous section arecomplimentary to each other. Activities based on these techniques arealways performed in parallel. Information gathered during entityrelationship modeling feeds the function model and vice versa. Newfunctions lead to the discovery of missing entities. Entity life-cycleanalysis can reveal missing functions; for example, a function may havebeen 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 theorganization. Process flow diagrams provide a horizontal view of theorganization, showing additional information on how the organizationaccomplishes specific repetitive tasks. Both views will increase yourunderstanding of the business and help you to identify missing businessfunctions (process steps).

Because of the complimentary nature of the techniques, the followingroad map only applies to the preferred sequence of activities withineach modeling area. As stated in the previous section, business rulemodeling should be regarded as a discipline on its own. However, assome classes of business rules are strongly related to either entityrelationship modeling or function modeling, the road map is organizedinto 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. Thefollowing table provides the modeling areas and the CDM tasks andtheir 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 FunctionModel

RD.070 Detailed Business Function Model Construct Detailed Business FunctionModel

RD.090 System Function Model Construct System Function Model

Authorization Rules

TA.090 Security and Control Strategy Develop Security and Control Strategy


Depending on the scope and complexity of your application system, andthe project approach applied, you will iterate more or less through thesteps of the working sequence. You will produce a high-levelrequirements model the first time, and refine this model in a laterround.

Deviations from the road map, given the choice of developmentapproaches, may occur in the sense that some steps, or a set of steps, arerepeated. Sometimes you can swap two steps or omit a step which isnot required, depending on your specific project situation.

Reference: The road map does not cover steps related toproject management and quality control. Refer to the ProjectManagement Method Handbook for more information on thesetopics.


Business Process Modeling (RD.010)

Process Modeling within custom development can be split in two mainsteps:

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 theprocesses in the business area. There are many other supportingprocesses, mostly low-level and consisting of a few elementary processsteps. Steps 3 to 5 use the technique of event-response analysis toidentify these processes.

1. Identify the Primary Processes

Identify primary processes by defining the business problems andbusiness objectives.

Reference: For more information, refer to the section,Modeling the Business Context, of Chapter 2, ProcessModeling.

ProcessModeller

Tools: Process Modeler

2. Define Business Units

Define the hierarchy of organization units.

Reference: For more information, refer to the section,Modeling the Business Context, of Chapter 2, ProcessModeling.

ProcessModeller

Tools: Process Modeler; Creating an Organization Unit

3. Develop Process Flow Diagrams for Primary Processes

For each primary process, identify the events, process inputs, andprocess outputs. Break the process down into process steps. Determinethe sequence of the process steps and define the process flows between


process steps. Identify process steps that represent a business decisionand define the outcome. Identify the agents performing the processsteps and decisions.

Reference: For more information, refer to the section,Modeling Business Processes, of Chapter 2, ProcessModeling.

ProcessModeller

Tools: Process Modeler; FileNew

4. Identify Events to which the Business Area Responds

Identify and describe external, temporal, and internal events.


ProcessModeller

Tools: Process Modeler; Create Trigger

5. Identify and Document Business Processes Associated with eachEvent

Identify and name the process associated with each event. Identifyprocess inputs and outputs. Describe the process. Identify currentsystems support for the process and identify business issues associatedwith each process.


ProcessModeller

Tools: Process Modeler; Create Process Step


6. Develop Business Process Flow Diagrams

Break the process down into process steps. Determine the sequence ofthe process steps and define process flows between them. Identify theagents performing the process steps. Consolidate process flowdiagrams for events that have similar responses.


ProcessModeller

Tools: Process Modeler; Create Process Flow

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 themechanism of process flows (electronic, hard copy, verbalcommunication, etc.). Define volume, frequency and availabilityrequirements for each process step.


ProcessModeller


2. Determine Interfaces with other Systems

Identify interfaces between the new application and other existingsystems.

Reference: For more information, refer to the sections,Modeling the Business Context, and Modeling BusinessProcesses, of Chapter 2, Process Modeling.

ProcessModeller



3. Develop System Process Flow Diagrams

Develop graphics to visually represent process steps with userinterfaces and include these where needed in the process flow diagrams.Depict interfaces to existing systems on process flow diagrams.

Reference: For more information, refer to the section,System Process Model, of Chapter 2, Process Modeling.

ProcessModeller

Tools: Process Modeler; Iconic Mode

Entity Relationship Modeling (RD.040, RD.060, RD.080)

1. Define Entities and their Relationships

Reference: For more information, refer to the section, Inter-Entity Rules, of Chapter 3, Business Rule Modeling. Youcan also refer to Chapter 4, Entity Relationship Modeling.

EntityRelat ion

Tools: Entity Relationship Diagrammer; Create Entity,Create Relationship

2. Define Attributes

Reference: For more information, refer to Chapter 4, EntityRelationship Modeling.

EntityRelat ion

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


Reference: For more information, refer to the sections,Inter-Entity Rules, and Recording Business Rules as aFunction, of Chapter 3, Business Rule Modeling.

EntityRelat ion

Tools: Dependent of the type of rule: Entity RelationshipDiagrammer

Funct ionHierarchy

Tools: Edit Entity Function Hierarchy Diagrammer; CreateFunction, Edit Function Text tabsheet

4. Add Entity Detail

Define Volumes, Synonyms and detailed Entity Description.

Reference: For more information, refer to the section,Adding Entity Detail, of Chapter 4, Entity RelationshipModeling.

EntityRelat ion

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.

Reference: For more information, refer to the section,Function Hierarchy, of Chapter 5, Function Modeling.

Funct ionHierarchy

Tools: Function Hierarchy Diagrammer; Create Function


2. Define Function Entity Usage and Function Attribute Usage

Reference: For more information, refer to the sections,Function Entity Usage, and Function Attribute Usage, ofChapter 5, Function Modeling.

Funct ionHierarchy

Tools: Function Hierarchy Diagrammer; Edit Function Entity Usage, Attribute Usage tabsheets

3. Add Function Detail

Define frequency, response (immediate or overnight), functionstriggered, and add function description.

Reference: For more information, refer to the section,Function Definition and Function Description, of Chapter 5,Function Modeling.

Funct ionHierarchy

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 aftera change in the state of the data (creation, update, or deletion of anentity or attribute) has taken place. This definition includes recordingthe triggering event.

Reference: For more information, refer to the sections,Change Event Rules, and Recording Business Rules as aFunction, of Chapter 3, Business Rule Modeling.

Funct ionHierarchy

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, userroles, and managers.

Reference: For more information, refer to the section,Authorization Rules, of Chapter 3, Business RuleModeling.

ProcessModeller

Tools: Process Modeler; Creating an Organization Unit

2. Define Function Access Rules

Define which business units are authorized to perform which functions.

Reference: For more information, refer to the section,Business Unit Data Access, of Chapter 3, Business RuleModeling.

ProcessModeller


Matrix

Tools: Matrix Diagrammer

R O N

Tools: Repository Object Navigator


3. Define Vertical Data Access Rules

Define business unit data access if severe data security requirementsapply to your application system.

Reference: For more information, refer to the section,Function Access Rule, of Chapter 3, Business RuleModeling.

ProcessModeller


Matrix

Tools: Matrix Diagrammer

R O N

Tools: Repository Object Navigator

Oracle Method Process Modeling 2 - 1

C H A P T E R

2 Process Modelinghis chapter describes guidelines for developing a process model. Itcovers the following topics:

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

T

2 - 2 Process Modeling Requirements Modeling using Oracle Designer

Related CDM Tasks

The guidelines in this chapter apply to the following tasks of theCustom 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:

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 workof an organization. It is based on the notion that an organization may beviewed as a system. Organizations, like systems, receive inputs andproduce outputs to their environment. Systems consist of subsystemsthat in turn accept inputs and produce outputs. In an organizationalsystem these subsystems are termed business processes. Processmodeling focuses development on these business processes, thereforeemphasizing the requirements most important to the business. Byfocusing 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 toachieve radical, order-of-magnitude improvements in the performanceof the business, BPR focuses on the primary business processes whichproduce visible output to the customer. These key business processesare reengineered to improve efficiency, reduce bottlenecks, andeliminate redundancy on an enterprise-wide level. Although BPR gainscan be quite significant, this level of effort requires the task to bemanaged apart from any custom development and will typically occurprior to software development. Business process redesign, on the otherhand, is a smaller scale task and fits within the scope of the CustomDevelopment Method.

Process modeling views business processes as systems which receiveinput, produce output, and are triggered by events. Process modelingspecifies each detailed step within a process which must be performedto transform the inputs into the process outputs. Additionally, processmodeling places every business process in its organizational context byshowing the organizational element responsible for each step in theprocess.

A process flow diagram(PFD) is a visual representation of the workflowperformed in the execution of the business process, as well as theinformation needs that arise during the execution. Some automatedapproaches to process modeling, such as Oracle Designer, are able todepict process executions that demonstrate timing of process steps andcan even include video and audio representations of process steps.


Benefits of Process Modeling

No single modeling technique can completely capture the entire set ofbusiness 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 relationshipdiagrams

Process models provide the customer and developer with a dynamicview of the business, one which describes the expected behavior of thesystem. Business process models represent work actually performed bythe users and are therefore more real to them while the other twomodels tend to be more abstract. The process models represent thework of the organization and show how information is used. Theoutputs they produce are tangible and essential to the organizationsmission. So, from the perspective of the customer, a process model is anintuitive and natural description of the business defined inunderstandable terms. These characteristics make the process model anideal feedback analysis tool. In a single view, the process modeldescribes business workflow in terms of the sequence of tasks, theparticipating organizations, and the events which initiate them.

Process modeling does not replace other modeling techniques in ourmethods toolkit. However, it provides additional analytical power andlends itself to the rapid development of high quality applications. As apowerful communications tool, an efficient technique for organizingand representing requirements, and as a springboard for applicationsystem design, process modeling provides the foundation for theanalysis and design of custom developed systems.

Downstream Benefits

In the development of user documentation and training, process modelshave proven to be an effective tool. Because the process model showswhich user roles are responsible for performing which process steps,training and user documentation can be designed for specific user rolesperforming specific process steps. This greatly increases the ease andefficiency of training material and documentation development.


The process model can also be used as a basis for developing testingscenarios. Module tests can be constructed around individual processsteps; module integration tests correspond one to one with processes;and system and systems integration tests can be developed for closely-related sequences of processes. Because the process model presents theuser view of the system, users can effectively participate in the design ofscenarios and test cases.

The Business Process Model

When we approach a client wanting a new system, our first task is todefine the business area that the new system will automate. To do this,we need to understand the clients objectives and the business processesthat the system will implement. We also need a way of understandingthe size and complexity of the business area. The Business ProcessModel provides an excellent means to understand, communicate anddocument these aspects of the business area.

The Business Process Model represents the business requirements that arewithin the scope of the project. The objectives of the business processmodel are as follows:

to improve communication between the business analyst andthe business client about how work is actually performed

to show the sequence of steps used to produce the processdeliverable

to show how different parts of the organization work togetherto execute a business process

to aid in identifying and evaluating process improvementalternatives

to provide a framework for the development of new orenhanced systems

The project team develops the Business Process Model during BusinessRequirements Definition. It is a complete process model representationof the business area. It includes the following:

a definition of all events to which the business area mustrespond, and the mechanism(s) used to recognize events

the sequence of elementary business functions that make up thecomplete response to each event


the agents that perform the process steps

process flow diagrams representing processing performed by allmulti-step processes in the business area

an identification of appropriate process steps as elementarybusiness functions

an identification of the inputs and outputs; a description of theprocessing for all elementary business functions; identificationof the agent, at the role level, that performs the elementaryprocess

Business Processes

A business process, in general, is the combination of operational steps andmanagement controls that, taken together, produce a product or delivera service. The central idea in this definition is that a business processproduces a result or output of some kind. The product or service maybe something that is received by an external customer, such as fulfillinga customer order. Other business processes produce outputs that arenot visible to the external customer, but are still essential to theeffectiveness of the organization. Taking inventory or hiring anemployee are good examples.

Business processes occur as preplanned responses to business events.An event is an occurrence inside or outside of the business environmentthat causes an event response to execute. Event responses follow anestablished, repeatable set of steps that make up the complete responseto the business event. The combination of an event and its eventresponses form a process. A planned response system is comprised of theentire set of processes in the business area. The Business Process Modelis the representation of the business areas planned response systems.

Processes may be modeled at different levels, depending upon thebreadth of the process steps that are defined. When performingbusiness process reengineering, an analyst usually works with high-level processes, analyzing these processes at a macro level. Customdevelopment and application implementation, on the other hand, mustultimately work with business processes at the elementary level.

The System Process Model

The Business Process Model reflects the requirements of the businessprocesses that are to be supported by the new system. It does not


address the technical requirements that must be met to satisfy the businessrequirements. This is the function of the System Process Model. TheSystem 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 executedwith the new system

The System Process Model expresses the technical characteristics of thenew system that must be fulfilled in order for the system to effectivelysupport the business requirements. Specifically, the System ProcessModel includes the following information:

for each process step, delineation of where the user interfaceboundary lies

for each event, the physical mechanism(s) by which the eventwill be recognized (that is, phone call, electronic transmission,batch operations schedule, etc.)

mapping of automated process steps to the types of processorsthat will execute them

for each process step, identification of the type(s) of userinterfaces to the system (that is, GUI, block mode, radiocommunications, hand held computer, etc.)

identification of electronic interfaces with other systems

a matrix cross referencing processes with the geographiclocations where they will be executed

By expressing requirements in terms of technical characteristics, theSystem Process Model is the bridge between the analysis of therequirements and the design of the application. There should besufficient information in the System Process Model for a systemarchitect to fully specify the technical architecture for the application.

Overview of Process-Oriented Development

In CDM, it is the Business Requirements Definition process thatidentifies and defines the business needs of the application. The taskswithin this requirements gathering process have a process modelingbasis. As an analyst, you must first determine which processes support


the organizations business objectives, thereby focusing the applicationdevelopment upon these primary processes. Next, identify the externalsystems and external entities which interact with the system as youhave initially defined it. This step sets the initial scope or context of theapplication. Typically, you create a context process model to capture thisinformation. The scope of the context process diagram should includeall primary processes and external agents.

The team builds a context model to illustrate function area context andhigh-level application system interfaces. Next, the top layers of thebusiness functions are organized into functional areas under thebusiness area. The Business Process Model is developed concurrently todocument all of the business events and subsequent responses that theapplication 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 inparallel with the function and process models to represent businessarea information needs. This process is illustrated further in figures 2-1and 2-2.


REPOSITORYNAVIGATOR

PROCESS

FUNCTIONDIAGRAMMER

ENTITYDIAGRAMMER

DATAFLOW DIAGRAMMER

ConstructBusiness Data

Model

BIM

ConstructBusiness Function

Model

BFM

CompleteBusiness Process

Model

BPM

ConstructContext Data Flow

Model(Optional)

CIM

Construct SystemData Model

SIM

Construct SystemFunction Model

SFM

Construct SystemProcess Model

SPMCreate Context

Process Diagram

CPM3

Define andValidate Business

Objectives

BOBJ

ID Business Units(Agents)

ORGS

ID ExternalInterfaces

CPM1

ID PrimaryProcesses

CPM2

A30.090

A20.090

A20.120

A20.100

A20.090 B30.110

B30.100

A20.090

A10.030

A20.110

A20.090

Figure 2-1 Business Requirements Definition Process

Oracle Designer Support

Oracle Designer fully supports the Custom Development Method inaddition to many other structured methods being used in industrytoday. In CDM, the Process Modeler is central to the BusinessRequirements Definition tasks and is used to describe both thebehavioral and functional requirements of the system. It provides agraphical interface into the repository allowing the team to define


business events, processes, flows and stores as well as organizationalstructures. The Process Modeler has additional capabilities to computethe critical path and animate the flows through each process.

When using the Process Modeler in Oracle Designer to document thebusiness processes, the function hierarchy is populated automatically.Each time a process step is created in the Process Modeler, it is stored asa business function in the Oracle Designer repository. Specifically, eachroot process is created as a root function and each process step within iscreated as a child function to the root. These two modeling tools areclosely tied together, accessing many of the same elements in therepository. Both tools must be used in a complementary fashion inorder to fully capture the business requirements. We discuss thisinteraction between the two models in detail later in the chapter.


Context Scope

Hig h-leve l

Busin essF un ctio n

M od el(BFM )

Initia lBusin ess

Da taM od el(BDM )

Fun c Def.

T op Laye rBusin essF un ctio ns

(BFM )

Business Layer

Co ntextM od el(CM )

Pro

ces

sFu

nc

tion

Dat

a

Busin essProc ess

M od el (BPM )

P rocess & Task Reference

Create (H igh-Level)Business P rocessM odel (R D.010/RD.011)z il lu s trate funct ion a rea c ontex tz show h igh-leve l interfacesz docum en t bus iness even tsz docum en t w ork f lowsz develop p roc ess and p rocess s teps (E B F s)

Create H igh-level /Com posite B usinessFunction M odel(RD.030/RD.031)z docum en t sc ope o f B Az o rgan ize app lica tion into F A sz

re-pa ren t/o rgan ize E B Fs unde r FA sz

rec o rd de ta iled EB F desc rip tionsz

docum en t referenc e en tity funct ionsz

rev iew sc ope o f E B Fs

Create Initia l/ H igh-Level Business DataM odel (R D.040/RD.041)z

z

docum en t bus iness da ta requ irem entsz c rea te bus ines s en tities , a ttr ibutes and re la tionsh ips

Proc essM od eller

P roc essM od eller

P roc essM od eller

F un ctio nH ie rarch y



EntityRe latio n

EntityRe latio n

Figure 2-2 Oracle Designer Support for Business Requirements Definition


Modeling the Business Context

If your project is large or moderately sized, it is good practice to buildone or more context process diagrams. A context process diagramprovides a process overview of the entire business area forunderstanding, discussion, and initial scoping. These diagrams help toorganize the processes on a high level and functions that you haveidentified at this point.

The Business Process Model represents the business requirements withinthe scope of the project. Although treated separately here, the ContextProcess Model is typically considered a part of the Business ProcessModel.

Business Area

When the need for a new system is determined, our first task is todefine the business area that the new system will automate. To do this,we need to understand the clients business objectives and primarybusiness processes. We also need some way of understanding the sizeand complexity of the business area. We can accomplish this byanswering the following questions:

How many processes are there?

How do the objectives of the project relate to the businessprocesses?

How many different agents are involved in executing primaryprocesses?

What information is needed for the processing?

Are the processes geographically dispersed?

The Context Process Model considers these issues by looking at thebusiness area as a system and its relationship to the environment. Thishigh level or contextual perspective provides a unique view of thebusiness area. It defines the scope by specifying what is inside thebusiness area and what is outside the business area.

The term business area is used to refer to the set of business processeswithin the scope of a custom development project. Although the projectsponsor drives the definition of scope, we use process modeling to


expose and clarify what is in scope. Once process-based functionality isunderstood we organize the business area by functional area in thefunction hierarchy. We may then use the function hierarchy to establishappropriate boundaries for the business area.

Defining Business Objectives and Primary Processes

In custom development, the primary purpose of process modeling is tofacilitate the development of a new system. Users want new systemsbecause they solve business problems. The first step in developing theBusiness Process Model is to document the business problem anddevelop a clear problem statement. This is accomplished by workingwith 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 doyou 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 ourcapacity to handle them. We are losing customers because ofit.

We get too many complaints from our customers that we arebilling them for the wrong products and amounts.

The next step is to recast the problem in terms of a set of businessobjectives. Objectives are business conditions which, if met, will solvethe business problem. Well-defined objectives are measurable and oftenrelate directly to business processes and deliverables. For example:

to reduce stock by 75% without increasing inventory carryingcosts

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, forexample: Replenish Stock, Review Proposals, ProvideCustomer Service, Bill Customers. Each business objective shouldtie to a business process. The set of business processes, identified inassociation with the objectives, represent the primary processes of thebusiness area.


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 aredetermined from business objectives. The remaining elements are bestillustrated by an example.

Example Hollywood Video Rentals

Description: Hollywood Video Rentals is a company with over 350outlets nationwide. Hollywood rents movie videos and computergames as their primary source of revenue. In addition, they alsosell videos, movie posters, and concessionaire snack items. Thecompany has recognized that the current process of procuring theirstock could use some improvement. Inefficiencies in the processare eating up profits.

Hollywood has identified the business problems and objectives for theStock Procurement business area shown in the following table.

PROBLEMS OBJECTIVES

Perceived lack of financialcontrol at Head Office

Provide visibility into stock procurement processesfor Head Office

Lack of standardized billpaying across locationsnationwide

Provide rental stores a streamlined and simplifiedprocurement process they will follow.


PROBLEMS OBJECTIVES

Excessive late payments tovendors. Incurring late fees.Some vendors now requestingadvance payment prior toshipping.

Reduce late payments to less than 1% of totalpayments.

Reduce errors on invoices and accounts to lessthan 1% of total payments.

Unable to perform effective cashplanning

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

Lack of centralized purchasingprocess. Unable to takeadvantage of volume discounts

Increase profit on unit items.

Maintain high demand, with latest and greatestitems in inventory.

The existing Accounts Payablesystem only handles PurchaseOrders, no alternative paymentmethods handled.

Take advantage of existing system capabilities.

Given this information and the current organizational structure,primary processes are developed which directly support the businessobjectives. It is important to determine the relevant organizational unitsand the primary processes they are responsible for. Each primaryprocess is added to the context process diagram in the responsibleagents channel. External interfaces are also included on the contextprocess diagram. Externals can be modeled as external agents oralternatively as process step in the Unspecified agent channel.Organizational units and external systems are discussed in thefollowing sections.


HEAD OFFICE

ACCOUNTS PAYABLE

PURCHASING

RENTAL STORE

Unspecified

PurchaseProducts

PURCHASE

Evaluate andTrack VendorPerformance

EVALVENDOR

Order ItemsORDER

Notify Storesof ProductAvailability

NOTIFY

ReceiveGoods

RECEIVE

ProcessInvoices

INVOICE

AwardContracts

CONTRACT

AutomatedAccounting

System (AAS)

Forecast CashRequirements

FORECAST

INVENTORY

E002

E001

Triggering Events:E001: End of MonthE002: Stock Low

Figure 2-3 Context Diagram for Stock Procurement

This context diagram captures the scope of the business area and alsoconveys a general flow of the primary business processes. We have alsodocumented primary business processes, their responsible agents, andall external interfaces all on a single diagram.

Notice that all the diagram elements are high level. The purpose of thecontext process diagram is not to capture detail, but to capture the scopeof the business area through high level processes and flows. You mayalso notice that the FORECAST process is not connected by any flows. Atthe context level it is possible that we have several independent primaryprocesses in our business. We may also define the external interfaces toour business by adding the external systems to our diagram as we havewith the Automated Accounting System shown in the Unspecifiedagent channel. Now, how do we create these diagram elements inOracle Designer?


Using Oracle Designer to Construct the Context Process Diagram

To create a new context process diagram, begin with a new root processcalled CONTEXT. This creates a separate hierarchy apart from anyfunctions you may have already entered into the repository. Select NewDiagram from the File menu, then click on the Create New Root Process inthe dialog box.

Create NewDiagram

Button

Create NewDiagram

Element Button

Create NewDiagram

Element Button

Figure 2-4 New Diagram, Create New Root Process

Once the new diagram has been created, organizational unitsrepresenting the business agents are added to the diagram. At thispoint, you may either create new organizational units or, if they alreadyhave been defined, you can include them by selecting the Include optionfrom the Edit Menu. Adding a process step or store is done in a similarmanner. Select the appropriate create button and click in the agentchannel where you wish to place the element.


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 informationabout the diagram element. This Edit Dialog Box behavior is standardfor all diagram elements in Oracle Designer.

Organizational Units (Agents)

RENTALSTORE

The agents that perform the process steps are shown to the left of theprocess rectangle. The rows running horizontally across the diagramserve to separate process steps performed by one unit from thoseperformed by another. Agent names should be singular nouns.

The horizontal strip associated with an agent is called a swim lane, oragent channel. In Oracle Designers Process Modeler, an agent isdefined using an organizational unit.

An agent refers to the party responsible for a process step. An agentmay be an organization, a functional unit such as a department ordivision, an employee role, or a party external to the organization, suchas a customer or supplier. In our example, RENTAL STORE and HEADOFFICE represent functional units in the organization while ACCOUNTSPAYABLE and PURCHASING represent departments within the HEADOFFICE.

ProcessModeller

Tools: When you decompose the Process Model into lowerlevels in Oracle Designer, it is probable that you will moveinto 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.

ProcessModeller

Tools: If you use sub organization units in Oracle Designer,it is possible to open and collapse the swimlanes, to eithershow only the top organization unit, or including thedetailed units. When the swimlanes are collapsed into thetop organization unit, all the steps in the detailed units willbe shown in that swimlane. Note however, when you openthe detailed organization units, the layout of your processeshave been changed.

There may be many agents that are involved in performing a primaryprocess. For instance, Purchase Products may involve the STOREMANAGER, the VENDOR and the HEAD OFFICE PURCHASING DEPARTMENT.In this case, you should indicate only the single responsible agent for theprocess 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 STORECLERK.

ProcessModeller

Tools: If there is a large amount of interaction between twoagents, it can simplify the diagram if they are placed next toeach other. To move an organizational unit, hold the controlkey while pressing the up or down arrows. To change theheight of the channel, hold the shift key and press the up ordown arrow keys.

Process Steps

Pay Supplier

AP 4.3.1 All process steps must have a name that begins with a verb. Namesshould be shown centered within the process step symbol. Include alabel 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.

ProcessModeller

Tools: To create the label in Oracle Designer, double-click onthe process step to edit the properties. Select the Multimediatab, enter the label in the text annotation field, and set theannotation type to Text.

Flows

A flow represents the sequential order of process steps. Primarilyused to show the order in which steps are performed, a flow may alsorepresent the movement of information or materials betweenindividual 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 aMaterial Flow. Flows can be drawn between the process steps in OracleDesigner and can be classified as one of the three above, or just as aFlow only. Only use this option if you do not yet know what kind offlow it is. Normally you would also include the Temporary Flows atthis level (for example, Year end processing).


It is often desired to be visualize the difference between the various typeof flows. You will not get this by default using Oracle Designer, but it isrecommended to provide this by using different line widths as shown inthe figure below.

Figure 2-5 Visualizing the Different Process Flow Types

The following drawing conventions are used for the flows:

Data : Standard arrow widthTemporary : Arrow with width 5 times standard widthMaterial : Light Gray arrow with width 5 times standard width

Events

E0123 Each process flow diagram may show one or more events. A contextdiagram can indicate one or more high-le

cdm vol1

Documents