BUSINESS PURPOSE
The purpose of this activity is to interpret the
information requirements as derived from the user in the
preceding activity and prepare a formal definition for
review with User Management in the next activity (E).
Further, the Project Scope is reappraised and updated as
required.
OVERVIEW
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:
- 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.
- 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.
- 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, the Systems Engineer 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:
<![CDATA[
CREDIT CARD NUMBER = FINANCIAL INSTITUTION ID + BANK CODE +
BRANCH OFFICE ID + ACCOUNT ID
TELEPHONE NUMBER = COUNTRY CODE + AREA CODE + EXCHANGE +
CUSTOMER 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.
- 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:
- RECEIVER - where the user receives the
information and is responsible for performing the action
and/or making the business decision.
- PARTICIPATOR - where the user receives the
information but takes no immediate action. In other words,
they are advised of the information ("copied" for example).
- 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."
NOTE: Use the "source" of primary data
elements that are Descriptive or Quantitative as the basis for
determining "originators." Indicative data will be used as keys
for a variety of situations. As such, its "source" will be less
important.
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 thus far will be assembled for
formal review during Activity E; this includes:
- Information Requirements - providing an
individual description of each requirement.
- Information Flow Diagram (IFD) - a schematic
which shows how information flows between users. Each
requirement is expressed, along with the related originators,
receivers, and participators.
- Project Information Flow - complements the IFD
by expressing requirement/user relationships in matrix format.
- Glossary of Terms - lists all of the data
elements associated with the information requirements in a
dictionary-like format. This is extremely useful for reviewing
the business definition of data elements with User Management.
It helps to clarify the meaning of each data element.
- Project Scope - Systems Engineering 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. As part of defining the
Information Flow, Systems Engineering may encounter additional
user areas who may be affected. The information "receivers,"
"participators," and "originators" ultimately define the
boundaries of the project.
- Current System Analysis - as prepared during
Activity B.
STEPS IN EXECUTION
- Based on the user survey of information requirements in
Activity C, Systems Engineering begins the process of
defining and sorting information requirements.
- Each information requirement is to be uniquely identified
by number and name. Also defined are the requirement's...
Characteristics - timing (Frequency, Offset, Response
Time) and type information (Policy, Control, and Operational).
Textual Description - featuring the Business Purpose of
the requirement, the Actions and/or Business Decisions
supported, and the Benefits derived from the information.
- For control purposes, the requirements are related to the
project (PD/IR relationship).
- Systems Engineering defines "application logical" files
(FD's) to represent the various Objects (Facts and Events)
associated with the information requirements. Each FD must
have a related DD to represent the primary key to the file.
After they have been defined, the FD's are related to the
information requirements (IR/FD Relationship).
- Systems Engineering determines all of the necessary data
elements that are required to support the information
requirements, both primary and generated. Any pertinent
data element that has already been defined in the IRM may
be re-used and related to the information requirements
(IR/DD Relationship).
Additional data elements may be defined as required. In
defining the data element, Systems Engineering concentrates
on the logical business characteristics of the data as
opposed to the physical. At this stage, each DD should
be uniquely identified by number and name. Each should
have a clear business definition (in Webster/Oxford-style
format). And each should have its "source" defined.
The "source" of primary data is the business function that
is ultimately responsible for collecting the data. The
"source" of generated and "group" data denotes data
dependencies. All generated/group must ultimately
originate from primary data.
- Systems Engineering determines the flow of each information
requirement within the enterprise. Functional Entities
(FE's) and/or Organizational Entities (OE's) represent
users involved in the information flow. The information
flow expresses:
- RECEIVERS - those users receiving and acting upon the
information.
- PARTICIPATORS - those being advised of the information
(but no immediate action).
- ORIGINATORS - those designated as the "source" of the
primary data elements.
- For each information requirement, there must be at least
one "receiver" and one "originator"; "participators" are
optional. Also, it is entirely possible for the same user
to be both an "originator" and "receiver" of the same
information requirement. FE/IR and OE/IR Relationships
are used to express the information flow.
- Systems Engineering prepares an Information Flow Diagram
(IFD) for the project. The diagram represents each
requirement included in the project, along with FE/OE
information flow that was just defined.
A supporting Project Information Flow matrix summarizes the
information flow also.
- Systems Engineering reviews and revises the Project Scope
as required. The scope must clearly state the business
problems/opportunities to be addressed by the project,
along with the areas of the business affected, both
directly and indirectly. The engineer references the IFD
and Project Information Flow which represents all of the
users involved with the project.
- Systems Engineering packages the deliverables developed
thus far and reviews them with Quality Assurance for
adherence to standards. Revisions are implemented as
required.
- Systems Engineering schedules a review meeting with
User Management and distributes copies of the deliverables
to the users for evaluation. The deliverables include:
- Phase Cover Page
- Project Scope
- Current System Analysis
- Information Flow Diagram (IFD)
- Project Information Flow
- Information Requirements
- Glossary of Terms
- Phase Review Checklist (abbreviated form for the items above)