These three levels of information relate directly to the three levels of business functions in an enterprise. Consult the "Universal Enterprise Model" in EEM for details.

The type of business activity ultimately relates to the types of OBJECTS being managed or manipulated. Objects are the facts and events needed to run a business. Facts tend to deal with tangible entities, while events are intangible; some examples:

Each level of business activity will affect Objects differently; for example:

Another interesting characteristic of information is TIMING. Information is a perishable and dynamic commodity. It only has value at certain points in time. This is because business actions and decisions must be made in specific time frames. Information delivered in the wrong time frame will be meaningless and not useful. It therefore becomes imperative to define timing with a high degree of precision. There are three time elements:

• FREQUENCY refers to how often the information is required. This is expressed by the number of occurrences within a time period. Some examples:

• OFFSET represents when the business process is to begin during the time frame. Some examples:

NOTE: There is no offset when the frequency is 'Upon Request' since information is needed at any moment in time.

• RESPONSE TIME is used to define the speed of the business process. Some examples:

These aspects to information timing will ultimately dictate the speed by which data must be collected, stored and retrieved.

It is a popular myth in the computer industry that "Users do not know what they want." Users may not know PHYSICALLY how they want the information presented (the output media), but they definitely do know what information they want. It is System Engineering's responsibility to ask the right questions of the user. However, the questions should be more oriented to the essence of business information and less on its physical implementation (which will be determined later).

Fortunately, the attributes of information, as defined by "PRIDE," becomes a convenient way for gathering and organizing user information requirements. As users are interviewed, consideration is given to:

• The LEVEL of information (Policy/Control/Operational).

• The OBJECTS managed or used (Facts and Events).

• The TIMING of the actions or decisions (Frequency/Offset/Response Time).

The "PRIDE" Information Requirement Worksheet makes a useful checklist for this type of questions. So much so, that users can complete the worksheet themselves.

The "PRIDE" Matrix Worksheet is also useful for organizing notes. For example, a matrix can be established showing time frames (Frequency/Offset/Response Time) and objects. The information levels (P/C/O) can then be expressed in the cell coordinates; for example:

For non-information systems related projects, the Information Requirement Worksheet can also be used to document non-information related requirements, such as equipment specifications. However, the Data Engineer should be cautioned not to confuse these type of requirements with normal information requirements.

INFORMATION REQUIREMENT (IR) DEFINITION

Lumping information requirements together in a disorganized manner serves no useful purpose. In fact, it will only cloud the meaning of the requirements. Instead, requirements should be segregated based on usage with a simple definition. There are three considerations for separating and sorting information requirements:

1. TIMING - Each requirement has its own unique time frame (Frequency, Offset and Response Time). This timing nuance represents the time frames when distinctly separate actions and/or business decisions are made. As such, a daily requirement should obviously be separated from a weekly requirement, monthly, yearly, etc.

2. LEVELS OF INFORMATION - There are distinctly separate types of actions and/or business decisions made within an enterprise. Executive decisions are substantially different than middle management decisions, which also differ significantly from routine operations. Because of this, information requirements are categorized by type: Policy, Control, and Operational.

3. RECEIVERS OF INFORMATION - for the sake of simplicity, information requirements are separated by the functional area being served. For example, the actions and/or business decisions made by the Sales function are substantially different than those made by the Manufacturing function.

NOTE: Two requirements could have the same timing and level of information, but used by different users for different business purposes.

The objective is to produce clean and concise information requirements that will be easy to understand by User Management.

Each information requirement should be defined in terms of:

• BUSINESS NAME - reference should be made to the timing of the requirement, along with the primary Object affected. Some examples: REQUEST CUSTOMER INFO, WEEKLY ORDERS, DAILY SHIPMENTS, MONTHLY BILLINGS, ANNUAL PRODUCT SALES, etc.

• CHARACTERISTICS - explicitly define the timing of the information (Frequency, Offset, and Response Time), and the information type (Policy, Control, and Operational).

• DESCRIPTION - textual narrative should express the Business Purpose of the requirement, the Actions and/or Business Decisions (WHO will do WHAT with the information), and the Benefits of the information (both tangible and intangible).

• RELATED OBJECTS - represent the primary Facts and Events pertaining to the information requirement. Objects are represented in the IRM by an "application logical" file (FD). Each FD should have one data element to represent the primary key to the file. For example, a Customer Object will use Customer Number as the primary key; a Product Object will use Product Number; a Billing Object will use Billing Number, etc.

• REQUIRED DATA ELEMENTS - define all of the data elements needed to support the information requirements. Existing data elements can be re-used or new Data Definitions (DD's) may need to be created. However, emphasis is placed on sharing and not creating redundant data elements.

  • Both primary and generated data elements need to be defined. The generated data elements are perhaps the most important to the user.

  • The physical characteristics of data is not required at this point, only the logical characteristics are needed to assure that the Systems Engineer has a complete understanding of the business facts required by the user. Attributes such as data length, class, precision, scale, picture, program label will be considered later. Currently, Systems Engineering must provide a simple business description of each data element, including a proper business name, definition (a Webster/ Oxford dictionary type definition), and source. For primary data, "source" refers to the business function that is ultimately responsible for initially collecting the data. For example, the Sales function may be responsible for collecting customer related data. "Source" also refers to the dependencies between data elements, such as those to produce "generated" data (A + B = C) or to represent "group" type data elements. A "group" data element represents a concatenation of other data elements, for example; CREDIT CARD NUMBER = FINANCIAL INSTITUTION ID + BANK CODE + BRANCH OFFICE ID + ACCOUNT ID TELEPHONE NUMBER = AREA CODE + EXCHANGE + ACCOUNT NUMBER

    All generated/group data elements must ultimately result from primary data elements. It is Systems Engineering's responsibility to assure that such dependencies exist.

    NOTE: Defining the data elements needed to support each information requirement is the responsibility of Systems Engineering, particularly generated data elements. Data Engineering will validate the various data definitions.

  • USERS INVOLVED WITH THE INFORMATION FLOW - This can be represented by Functional Entities (FE's) and/or Organizational Entities (OE's). "Information flow" pertains to the user's relation to the information requirement, which may be one of three types:

    1. RECEIVER - where the user receives the information and is responsible for performing the action and/or making the business decision.

    2. PARTICIPATOR - where the user receives the information but takes no immediate action. In other words, they are advised of the information ("copied" for example).

    3. ORIGINATOR - where the user represents the "source" of the primary data elements used to produce the information. In other words, "source" as expressed on the DD becomes the criteria for assigning "originators."

  For each information requirement, there must be at least one "receiver" and one "originator"; "participators" are optional and will typically pertain to OE's, not FE's. Also, it is entirely possible for the same user to be both an "originator" and "receiver" of the same information requirement.

  DELIVERABLES

  The deliverables produced in this activity will be reviewed in the next activity (D). They include:

  • Information Requirements - providing an individual description of each requirement.

  • Information Requirements/Objects Matrix - expressing the relationships between IR and FD resources within this project. If an EEM project, this matrix will not be pertinent since "Enterprise Logical" objects are considered (not "Application Logical").

  • Project Scope - Data Engineering and Project Management updates as required the Project Scope. The scope is used to define the business problems/opportunities being addressed by the project, along with the organizational areas affected by the project, both directly or indirectly.