PRIDE ® -ISEM
Information Systems Engineering Methodology
PHASE 1 - SYSTEM STUDY & EVALUATION
ACTIVITY C - SURVEY INFORMATION REQUIREMENTS

EXAMPLES   TOOLS & TECHNIQUES   FUNCTIONAL MATRIX   CHECKLIST   SUPPORT   FORMS

TRANSLATE THIS PAGE TO... Chinese (simple)   Japanese       Dutch   French     German     Italian    
Free Translation courtesy of ALS      Chinese (traditional)   Korean       Portuguese       Russian       Spanish         

CONTENTS

This section contains the following:


 
    BUSINESS PURPOSE

    The purpose of this activity is to survey user information requirements.  

    OVERVIEW

    Whereas Activity C is used to gather details regarding requirements, Activity D will be used to analyze requirements, and Activity E will be used to confirm them with User Management. This is analogous to a doctor/patient relationship where symptoms are described by the patient, and the doctor prepares a diagnosis of the problem.

    A review of the differences between Information and Data is essential at this point. Briefly, data is the raw material needed to produce information. Data is the representation of a fact or an event. By itself, it is meaningless. Data is entered and stored (not Information). To produce information, data must be accessed at a certain point in time and in a prescribed format. Information can be acted upon and generally adds insight to business activities. As such, INFORMATION IS THE INTELLIGENCE OR INSIGHT GAINED TO SUPPORT BUSINESS ACTIONS AND DECISIONS. The litmus test for information if whether the user can act on it or not; if the user can, then it is information; if not, then it is nothing but a random collection of data. In the computer industry, it has become common practice to produce more data and less information.

    Information varies according to its end use. For example, the department manager, vice president, and shipping clerk all require information about shipments. The same data may be used in all instances, but how this data is processed and reported as information will be considerably different for each business use. For example, the shipping clerk may only require shipping instructions. The department manager may need to know what is being shipped, where and how. The vice president may require a summary with comparisons over time. This means that there are THREE LEVELS OF INFORMATION within an enterprise:

    1. POLICY Information supports executive actions and decisions.

    2. CONTROL Information is used to implement policy decision and monitor operations.

    3. OPERATIONAL Information supports the routine operations of the business.

    These three levels of information relate directly to the three levels of business functions in an enterprise. Ideally, the Systems Engineer should access a Function Chart (as prepared under EEM) which will act as a roadmap for the engineer when interviewing users. 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:

    FACTUAL OBJECTS EVENT OBJECTS Customer Billing Employee Order Product Service Part Request Vendor Purchase

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

    POLICY LEVEL Forecast ORDERS CONTROL LEVEL Monitor ORDERS OPERATIONAL LEVEL Process ORDERS

    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. Under ISEM, 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: 4N = Four times each minute 4M = Four times monthly 30H = Thirty times each hour 1Q = Once a quarter 2D = Twice daily 2Y = Twice a year 1W = Once a week R = Upon Request (anytime)

    • OFFSET represents when the business process is to begin during the time frame. Some examples: 1D = First day (of a weekly process) 15D = Fifteenth day (of a monthly process) 2W = Second week (of a quarterly process) 365D = 365th day (of a yearly process)

      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: 5S = Five seconds 10N = Ten minutes 1H = One hour 2D = Two days

    These aspects to information timing will ultimately dictate the speed by which data must be collected, stored and retrieved. Of the three timing elements, Frequency and Offset are perhaps the easiest for the user to define. The definition of Response Time may be left to the discretion of the Systems Engineer to interpret and define.

    APPROACH

    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 ISEM, becomes a convenient way for gathering and organizing user information requirements. As Systems Engineering interviews User Management, they will consider:

    • 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).

    Systems Engineering will use these elements as the basis for developing the user's interview outline. During the information survey, Systems Engineering will need answers to the following types of questions:

    1. What is the business purpose of the information? (What is to be achieved?).

    2. What are the Objects being managed or operated? (What Facts and Events pertain to the user?)

    3. Who will use the information and how? (What are the actions and/or business decisions?) (When you receive the information, what will you do with it?)

    4. When and how often is the information needed? Why? (Frequency, Offset and Response Time).

    5. What are the benefits of having this information?

    6. What data is required? (Particularly generated data elements).

    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 and objects. The information levels (P/C/O) can then be expressed in the cell coordinates; for example:

    TIMING (F/O/R) ACTIONS/OBJECTS R/ /1H 1D/8H/1H 1W/5D/1H 1M/30D/1D --------------------- -------- -------- -------- --------- Process ORDERS O Monitor ORDERS C Forecast ORDERS P Prepare SHIPMENT O Regulate SHIPMENTS C --------------------- -------- -------- -------- --------- P=POLICY C=CONTROL O=OPERATIONAL

    During the user interviews, it is important that Systems Engineering not comment about the ease or difficulty of obtaining the information. The engineer should not comment as to whether it is practical or not. The primary concern is to direct attention to capturing the business requirements for information. Feasibility will be considered in Activity F. Systems Engineering does a great deal of listening and searching for subtle variations or hidden requirements. The manager may ask for one thing and actually require something quite different.

    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 Systems Engineer should be cautioned not to confuse these type of requirements with normal information requirements.  

    STEPS IN EXECUTION

    1. Systems Engineering researches the functional areas to be studied and the information topics to be investigated. In particular, a tentative list of the following items is developed for research:

      • Functional Entities (FE) - specifying pertinent business functions associated with the project.

      • Organizational Entities (OE) - specifying the jobs/positions associated with the project.

      Where available, pertinent Function Charts and Organization Charts should be obtained to assist in this regard.

    2. Systems Engineering prepares an interview outline and schedule to survey user information requirements.

    3. Systems Engineering conducts the survey as per the outline and schedule.

    4. Systems Engineering gathers and organizes all notes related to the information requirements.

   


Copyright © 1971-2008 by M. Bryce & Associates
Palm Harbor, Florida, USA
All rights reserved.