SE735 - Data and Document Representation & Processing

Lecture 8 - Analyzing Document Context of Use and Business Processes

Generic Requirements

· Automated information capture. Eliminate manual entry (or reentry) of information when documents are created, reusing as much as possible from other documents or sources.

· Straight-through processing. Minimize the need for any human intervention as a document flows through some specified processes.

· Timeliness. Make information available to those who need it when it is needed and when promised, and update it promptly when it changes.

· Accuracy. Ensure that every piece of information in a document is correct.

· Completeness. Ensure that a document contains all the information it should or that its recipient (person or application) expects.

· Automated validation. Provide a schema or specification that enables information to be validated.

· Interoperability. Enable information to be used “as is” or via automated transformation by systems or applications other than the one that created it.

· Standards compliance. Conform to regulations or standards for information accessibility, availability, security, and privacy.

· Customizability. Facilitate the internationalization, localization, and subsetting of information.

· Usability. Present information in a format or medium that is easy to use and understand by its intended users.

· Identifiability. Ensure that the design or appearance of a document signals that it comes from our organization or company; also called branding of the information.

Context and Requirements

· Organizational, architectural, process, and information patterns are clusters of requirements

· Most requirements can be identified by using patterns, but identifying the rest will take more effort.

Context and Perspective: Cooking School, or Restaurant?

Patterns as Reusable Combinations of Requirements

The context of use for Context C is covered by a common context pattern defined by Requirement 4, a shared contextual pattern with Context B as defined by Requirement 5 and its own specific Requirement 6.

Context and Selecting Patterns

· Much of what businesses do for themselves and with other businesses can be described using a small repertoire of supply chain or other business process / transaction patterns

· Each of these patterns implies a set of documents and some choreographies of document exchanges

· Selecting an appropriate pattern will help expose the information requirements, rules and constraints for our subsequent document analysis and design

· Choosing a pattern suggests which document payloads we'll need to find or design and in which business processes we are likely to deploy them

· How we describe context influences what patterns we identify and how we apply them

Business Process is the Most Important Context Dimension

· Business processes are the most important context dimensions because they highlight roles, perspectives, and strongly shape the information requirements

· For example, contextualizing a simple procurement pattern to have the seller and buyer in different countries adds new processes and documents

Simple Procurement Pattern

· A buyer party, a seller party and a carrier party (to ship the goods).

· This generic pattern includes the business processes and roles for the participating businesses

Context Dimensions

· The notion of context dimensions helps us more easily reuse sets of requirements

· Informal context dimensions can aid in understanding patterns of requirements.

Imported Goods Procurement Pattern

· Suppose we refine the generic procurement pattern to locate the seller party in another country.

· We have now created an imported goods procurement context

Original Pattern	Updated Pattern

Comparing these two models reveals some additional requirements for the imported goods context:

· Two new roles of broker and customs are involved because they are dependent on the seller party.

o If the seller party is not in the same country as the buyer party, we need additional roles in our process.

· Additional transactions and related documents that are dependent on this new context.

o Must arrange customs clearance and have the goods inspected.

· All these new roles, transactions, and documents are dependent on the primary roles, transactions, and documents.

· The context of use establishes the dependencies of the business process and exposes the underlying reusable patterns.

Other Context Dimensions

· Product Classification

· Industry Classification

· Geopolitical Classification

· Legal or Regulatory Jurisdiction

· Business Process Role or Supporting Role

Representing Context in Document Architecture

What Are Requirements?

· Once a problem or opportunity is defined and scoped, any constraints on possible solutions or goals that must be satisfied can be viewed as REQUIREMENTS: conditions that must be met for the solution to be acceptable

· Requirements are most often functional: descriptions of what the solution must do or must enable someone to do with it

· Requirements can be expressed in terms of quality attributes (often called the "ilities" – usability, reliability, portability, interoperability, maintainability, etc.)

· Requirements do not dictate how the solution is to be achieved – that is the responsibility of design

Some Important Caveats

· Document Engineering focuses on the requirements for information and process models and by their computer-processable implementations

o Requirements for the associated software applications are obviously important, but Document Engineering has nothing special to say about them...

o ... often because the models will be deployed using an existing software platform

o ... or because the constraints and business rules captured by the models are simply the most important ones

· Many of the information requirements in document-intensive contexts are contained in existing documents

· There is no sharp line dividing "requirements analysis," in which we get requirements from people, and "document analysis," in which we obtain them from documents.

Responsibility vs Task-Centered User Classification

· It is usually easy to identify people on the basis of their job titles or formal roles in the organization or environment that you are trying to understand – "system operator," "programmer," "shipping clerk," "truck driver," "professor," etc.

o It can seem straightforward to define requirements in terms of applying technology to the tasks that are defined by these job descriptions (example: "enable the system operator to manage multiple systems"

· But this is less useful than classifying people on the basis of what they really do or what their actual responsibilities are, and the titles or formal roles may offer little help in discovering this

o Job titles and formal organizational structure may not reflect what people actually do or what they might be doing better. Their job titles might make it difficult for them to tell you

Responsibility-Centered Classification and Requirements

· Once you think in terms of responsibilities, you can define requirements in terms of satisfying them, which should produce better requirements

· The tasks that people currently perform (or the documents they currently produce or use in performing them) might be constrained by their current systems or lack thereof. A new system (or new documents) might support better ways of meeting the responsibilities.

Methods for Identifying Requirements

· Studying people or phenomena in their natural surroundings as an anthropologist or ethnographer:

o observing and listening without trying to influence

o asking questions in a non-judgmental way

· Conducting face to face interviews or structured group sessions

· Requirements "meta-models" or templates or lists of questions can yield more complete and consistently specified requirements

· There are always lots of things people want to tell you if they trust you but which they will never write down

Paving the Cow Paths

· In "document-intensive" processes (especially those where the documents are paper ones) it is seductively easy to define a requirement of "replacing paper forms with online ones" while otherwise leaving the basic processes the same

· But this assumes that the product (or document) was designed to meet requirements in the first place and that these original requirements haven't changed

· Most people concede that the "naturalist" perspective is needed if you're designing a new system or a new product (or a new document)

· So taking time to identify requirements is desirable, if only to validate existing requirements, and it also ensures that important explicit and tacit knowledge isn't lost

Clarifying and Validating Requirements

· If you did your job well in the "naturalist" phase, you can test your understanding of the requirements by conceptualizing alternative ways to satisfy them and trying to "sell" these to the people giving you the requirements

· Testing your understanding means you won't end up "blaming the victim" for not expressing requirements correctly

· Get people's impression of whether your approach would meet the need in an acceptable and usable way

Communicating Requirements

· The analyst is the "communication middleman" between the customer and the developer, and often between other types of stakeholders

· The analyst translates technical language into business language and vice versa

· An intermediary is necessary because the customer and developer speak different languages

· So the analyst needs to be able to speak the language of both the customer and the developer

Specifying Requirements

· Requirements can be quantitative or qualitative, but in all cases should be verifiable

· PROCESS and DOCUMENT requirements are often closely related, and diagrams that depict their relationships – process / choreography / orchestration model that show document exchanges – are extremely helpful in ensuring that requirements are complete and consistent

· Specifying requirements using something like "simplified technical English" makes them easier to validate and communicate

· "Business Rule" is an up and coming buzzword in information systems that refers to a formal or refined statement of an requirement that is expressed in a technology-independent fashion

Simplified Technical English (STE)

· Simplified grammar - short sentences in active voice, simple verb tenses

· Simplified logic - temporal or structural ordering of sentences with explicit "control flow"

· Controlled vocabulary - approved and unapproved terms, used consistently

STE Example

BEFORE: Gain access to blade. After removing old blade, new blade may be fitted by proceeding in reverse order, using gloves to avoid injuries by teeth of blade. Before you attempt any of the above, the power should have been switched off.

AFTER: Make sure that the on/off switch is in the "off" position. Remove the blade cover from the machine. Warning: wear gloves when you touch the blade. Remove the used blade. Install the new blade. Install the blade cover

Common Errors in Specifying Requirements

MISSING ACTOR: "If the order is incomplete, then..." – Who determines that the order is incomplete?

FLOW BREAK, NULL "TRANSFER OBJECT" : "The clerk informs the manager" - How? By sending a document?

INCOMPLETE CONDITIONAL: "If x, then y" - What happens if not x?

"OTHERWISE" ORPHAN: "Otherwise" or "else" clauses that aren't preceded by and related to an "If" clause

INCONSISTENT NAMES: Are the "project lead," "project manager," and "lead engineer" the same actor?

Classifying Requirements in Document-Intensive Contexts

SOLUTION requirements – the functional, performance, quality attributes

INFORMATION or DATA requirements – what information is needed, what are its datatypes, possible values

DOCUMENT or STRUCTURE requirements – how is the information organized / assembled / packaged into sets of related information

PRESENTATION or SYNTACTIC requirements – how is the information presented or formatted or rendered – the physical or output model

PROCESSING and USAGE requirements – what relationships between documents have a business purpose

Categories for Business Rules

· There are many different schemes for categorizing requirements or business rules.

· Most approaches distinguish constraints on content that are represented in data models from constraints on behavior represented in process models

· Other schemes distinguish single-item constraints that must always be true from those that reflect the relationship between two or more items or that can change according to a process context

· Constraints can also be classified according to the manner in which they are represented and enforced in an implemented application

Expressing Requirements as Rules

Rules that Apply to Conceptual Models

· Semantic

· Structural

· Usage

Rules that (Can Also) Apply to Physical Models

· Syntactic

· Processing

· Presentational

Rules that Apply to Instances or Implementations

· Content

Semantic Requirements

Define the meanings of components by specifying properties, dependencies, or roles as generalizations or specializations of other components.

· The most important requirement in achieving interoperability is semantic agreement

Semantic Rules

· Establish properties: "The Order Number is an identifier that is unique to the Buyer"

· Express generalizations: "An Auto is a type of Vehicle"

· Expose dependencies: "The Price of an Item can depend on the Buyer"

Structural Requirements

Define co-occurrence or aggregation relationships between components.

Structural Rules

· Structural rules determine the assembly of components into documents

· Examples:

o "Each Illustration must have a Caption"

o "Every Order must have an Order Number, a Buyer and an Issue Date"

Usage Requirements

Define the policies or privileges that govern user access to information or applications.

Usage Rules

· Often based on organizational roles or responsibilities

· Example:

o "An Employee Salary can be viewed by a Manager but can only be changed by someone in the Human Resources Department"

Syntactic Requirements

Concern the form in which documents or processes are encoded in a physical or implementation model.

Syntactic Rules

· Might specify a particular XML vocabulary

· Examples:

o "All Purchase Orders must be encoded according to ANSI X12 850"

o "All Purchase Orders must conform to the Universal Business Language"

Process Requirements

Define actions to be applied whenever a given condition or set of information is encountered.

Processing Rules

· Also called Procedural or Behavioral rules

· Process rules provide the bridge between documents identified in a business transaction and the components needed by those documents.

· Examples:

o "The Seller will respond to an Order with an Order Response"

o "If the Item is Out of Stock, create a Back Order Request"

o "If the Customer Account Balance is greater than $1000, do not allow any more purchases"

Presentational Requirements

· Govern the appearance or rendering of information components.

· Presentational requirements are more common in publication-type documents because their rules are important to people.

· Presentational integrity is a stringent requirement, often mandated by legislation or contracts, to reproduce a document exactly as it appeared in its original presentation

Presentation Rules

· Examples:

o "The Item Description must be adjacent to the Product Image"

o "The Title should be centered"

Instance Requirements

· Establish rules or constraints about the values of information components or dependencies among them.

· A document model might follow all semantic, presentation, structure, syntax and processing rules but an instance of the document might fail to satisfy instance rules.

· Referential integrity is a special instance requirement to keep dependent information synchronized throughout a document

· Content integrity is another special requirement that seeks to preserve the content (but not necessarily the presentation) of the original document.

Content Rules

· Examples:

o "The Total Value of an Order cannot exceed $100,000"

o "The Currency Code should be expressed using ISO 4217 codes"

o "The Shipping Address must be the same as the Billing Address"

o "The Start Date must be earlier than the End Date"

o "The Customer's Account Balance must be greater than 0"

Combined Rule Types

· "If the Purchase Order Amount exceeds $10000, the Party must supply a Duns Number"

· "If the Customer's Account Balance exceeds $1000, display it in Red"

· "If the Customer's Account Balance exceeds $10000, send a Past Due

· Reminder by email, fax, and voice mail"

Requirements in the Model Matrix

Rule Types and Context Dimensions

Requirements are arranged according to their types and context to assess how much of the universe we’ve covered.

Example: An export broker buying aircraft fuel in Japan for shipment to Korea.

· ebXML project proposed eight dimensions suitable for describing business-to-business global trade

· The documents required in this situation would need information appropriate for contexts such as:

1. Business Process = Procurement

2. Product Classification = Aircraft Fuel

3. Industry Classification = Petrochemicals

4. Geopolitical = Japan

5. Official Constraints = Export

6. Business Process Role = Buyer

7. Business Supporting Role = Intermediary

8. System Capabilities = ?

· Each of these values would have associated with it sets of rules that satisfy the requirements for that context dimension, and taken together they would form the set of requirements for the unique situation defined by all eight dimensions

Context Dimension	Type of Rule	Example
Business Process = Procurement	Semantic Process	Every offer must have a unique identification. Every offer must have an acceptance transaction.
Product Classification = Aircraft Fuel	Structural	An item is identified by both quality and a batch number.
Industry Classification = Petrochemical	Structural	Hazardous regulations may apply that involve supplementary information components.
Geopolitical Environment = Japanese	Semantic Content	Parties are identified using Japanese business registration identifiers. Japanese business registration identifiers must be valid.
Official Constraints	Process Presentation	Certificate of Origin must be supplied on delivery. Bill of Lading must conform to the UN Layout Key.
Business Process Role = Buyer	Process	Specify party to organize delivery.
Business Supporting Role = Intermediary	Process	Separate Offer and Acceptance transactions are reflected from the ultimate Buyer to the ultimate Seller.

Analyzing Business Processes

o Internal processes can change but the external business interface should not.

o Business process models will contain some information components and document models will contain some processing rules

o Business processes can be described at many levels of abstraction

o There are no necessary relationships between business processes, management structure and facilities, technology, and systems

o The model of business organization shapes the need to exchange information across organizational boundaries.

Generic Assessment Question #1

Why is your organization considering web services and XML?

o We could be more responsive to our suppliers and customers, we could process and generate the appropriate business documents more accurately and quickly, and we could provide customers with a personalized catalog from our "content database"

o Web services will reduce our costs of doing business

o Our competitors are adopting web services and XML and we have to keep up

o Our engineers think they can do some exciting stuff with XML because they've found some cool open source tools

Generic Assessment Question #2

Which of the following best describes the overall process by which your documents or publications are created?

o There is an explicit and formal step-by-step process that is generally followed; our documents and publications are produced on time and meet explicit quality criteria

o There is an explicit and formal step-by-step process, but people sometimes "work around" it

o The process is informal, but people are usually successful at producing documents and publications on time with acceptable quality

o The process is informal, and there is sometimes a panic or crisis atmosphere, but we usually manage to get the documents and publications out when we have to

o We have no process, and we sometimes just publish whatever information we have when the product is ready to ship or when the customer demands it, even if we know the documents aren't complete or entirely accurate

Documents and Processes -- Yin and Yang

Modeling Documents {and,vs,or} Modeling Processes

o A document exchange consists of both the documents and the processes that produce and consume them

o By understanding the information in the documents, we learn what kinds of processes are possible

o By understanding the processes, we learn what kinds of information are needed

What's A Process? #1

What's A Process? #2

Why We Analyze Business Processes

o To ensure that all participants, stakeholders, software providers, standards developers, etc. have a common understanding of the enterprise and business domain

o To understand the enterprise independent of its current or future technology

o To identify and understand gaps, inefficiencies, overlaps, and opportunities

Business Process Analysis

o We perform an "as-is" analysis of how the enterprise conducts its activities today

o We identify requirements that may result in new or revised activities / processes / transactions – the "to-be" model

o We look for existing patterns or opportunities to use patterns in the models

o We may "re-engineer" the "as-is" model to optimize the processes; this is business process design

The Business Process Analyst (1)

o Document engineering involves the analysis and modeling of both business processes and "documents," but it is useful to describe business process analysis as a separate specialty

o The primary roles of the business process analyst are those of any analyst (and those are?)

o Additional required skills

§ Ability to view and analyze a problem from the viewpoint of business goals, business requirements, and processes

§ Familiarity with business reference models

§ Less need for technology and implementation skills than the Document Analyst

The Business Process Analyst (2)

o The business process analyst asks many of the same questions as the document analyst but the focus is on understanding the processes that produce and consume documents rather than on the documents themselves

o The business process analyst needs to be comfortable talking with people at many organizational levels, from "factory floor" workers to executives

The Abstraction Hierarchy in Process Models

o The fundamental difference between document models and process models is the range of abstractness / granularity with which you can describe processes

o We can model processes at an organizational level from the perspective of the nature and pattern of "value exchanges" between an enterprise and its suppliers, customers, and other entities in its "value chain" -- we see these at the highest levels of SCOR, RosettaNet, MIT Process Handbook

o A group of interconnected or choreographed transactions as a construct in a process model is what we most often mean by "business process"

o Documents and processes are at the same abstraction level when we focus on business transactions

Making a Pizza

1. Select recipe

2. Turn on as many lights as necessary to ensure adequate lighting in preparation and cooking area

3. Assemble required ingredients after washing and drying hands.

4. Sift 1/2 kg of flour into a large mixing bowl (preferably plastic), and then add a pinch of salt and pepper

5. Follow the rest of the preparation instructions in the recipe to make the pizza.

6. Pre-heat the oven to 350 degrees Fahrenheit.

7. Open the oven door, place the pizza in the oven, and close the door.

8. When the pizza is done remove it from the oven

Levels of Abstraction in Pizza Process Models

Business Process, Collaborations, and Transactions Conceptual View

Business Process Modeling Artifacts

Business domain view worksheet

BUSINESS DOMAIN VIEW WORKSHEET
Worksheet ID	UCBCalendar-BDV-1.0
Business Domain Model Name	Event Calendar Network
Industry Segment	Public University
Relevant Standards or Reference Models	SKICal
Domain Scope	Describe upcoming events and publish them on one or more calendars
Business Justification	Improve efficiency in producing calendars and publicizing events Enrich the academic, cultural, and social experiences of members of the university community

Business process area worksheet

BUSINESS PROCESS AREA WORKSHEET
Worksheet ID	UCBCalendar-BPA-1.0
Business Area Name	Central calendar
Description	Parties submit event information to Public Affairs Department for publication in university calendar
Scope	Decentralized culture of university rules out a general-purpose content distribution system; focus on semantics and processes of event calendars
Stakeholders	Primary: event submitters, calendar administrators Secondary: students, staff, faculty, public
Process Areas and Business Processes	Maintain events · Submit event · Review event Publish calendars · Request calendar · Assemble calendar · Distribute calendar
Process Goals	Efficient event submission Secure and reliable event maintenance Prompt publication to interested parties and relevant calendars
Constraints	Need a common model of “event” Calendar administrators must be able to approve events before publication

Business Process Use Case Worksheet

BUSINESS PROCESS USE CASE WORKSHEET
Worksheet ID	UCBCalendar-BPA-MaintainEvents-1.0
Business Process Use Case Name	Maintain Events
Description	Events submitted to main calendar are first reviewed by calendar administrator Submitter is informed of approval or rejection. Approved events are entered into the central calendar Changes to approved events may be updated in the central calendar
Actors	Event submitter, main calendar administrator
Preconditions	Event submitter must be authorized individual or organization
Begins When	Event submitter fills out “submit event” form
Ends When	Expired or cancelled events are deleted from the central calendar
Constraints	Event submitter must be notified of acceptance or rejection within reasonable time (TBD)
Exceptions	Event rejected
Postconditions	Event published in main calendar

A more formal modeling artifact for process models is a UML use case diagram

o It is relatively straightforward to derive a use case diagram from information collected in a business process area worksheet or a business process use case worksheet

Analyzing Business Transactions

o Business transaction – describes the exchange of documents and business signals in a trading or commercial relationship between two parties.

o A transaction implements a binary relationship between two parties, one playing the requesting role and the other the responding role.

o Some questions to be answered to analyze processes at the transactional level:

o When does the transaction take place?

o What transactions precede and follow the transaction?

o What information is needed to start the transaction?

o What information is produced by the transaction?

o What can go wrong?

Describing Transactions

Sequence Diagram

A Transactional Model of a Procurement Process with GMBooks.com.

Documents in Transactions

Business Transaction View Worksheet from Event Calendar Network Project

BUSINESS TRANSACTION VIEW WORKSHEET
Worksheet ID	UCBCalendar-BTV-SubmitLocalEventToMain-1.0
Business Transaction Name	Submit Local Event to Main Calendar
Description	Submission of event from local calendar to main calendar for publication and further distribution
Transaction Pattern	Offer-Acceptance
Initiating Partner Type	Local calendar administrator
Responding Partner Type	Central calendar administrator
Preconditions	Event accepted for local calendar
Begins When	Local calendar administrator fills out “submit event” form
Ends When	Central calendar administrator sends “accept event” or “reject event” message
Exceptions	Events can be rejected as inappropriate for central calendar
Constraints	Submitted event should be acknowledged on receipt Acceptance or rejection should be determined within 24 hours of submission
Postconditions	Local event republished on central calendar

Business Signals: Receipts and Confirmations

o Business signals are used by applications to inform the other side of certain types of events.

o Business signals and many types of business documents function as business acknowledgments

o Signals keep transactions and collaborations synchronized.

o The Three Types of Business Acknowledgments:

Transaction Patterns

Offer and Acceptance o Also called the Commercial Transaction pattern. o One party sends an offer and exposes itself to the imposition of legal liability by another in doing so. o A common example of this transaction pattern is that of placing an order
Request and Response o Used when one party makes a request for information and the responding party has to apply some business logic before responding. o Request Catalog would be an example of the Request and Response pattern if the catalog were tailored for each customer.
Request and Confirm o Used if a request for information assumes a previously established contract or obligation o One party requests confirmation or status information from another o For example, GMBooks.com example the Query Delivery Status transaction is an instance of this pattern
Query and Response o The response provided doesn’t depend on an established business relationship. o Used when the information being sought is static or slow changing so that it doesn’t depend on the identity of the party initiating the transaction o Request Catalog and its response would be an example if the catalog were static and every customer received the same one.
Notification o One party informs the other about the status of an existing business relationship or obligation o If GMBooks.com notifies the customer when the book is shipped from the distributor, that would be an instance of the Notification pattern
Information Distribution o Used for syndicated information exchange. o Similar to Query and Response but doesn’t require a responding business document because the relationship between the sender and receiver is informal rather than contractual. o If GMbooks.com wanted to send out promotional material or catalogs to potential customers, they would probably adapt an Information Distribution pattern

Analyzing Business Collaborations

o A business collaboration as a set of transactions with meaningful and necessary semantic or temporal overlap with each other.

o The business rules associated with each transaction, such as the preconditions, postconditions, and triggering events can identify relationships and dependencies between the transactions in a collaboration

o For example, the business rule that “Goods must be delivered within 48 hours of receiving the order” creates a collaboration by connecting an order transaction to those related to fulfillment

o e.g. Collaborations in the GMBooks.com Scenario