Atwater, Lantz, Hunter & Co.

submit 1099s  |  Prototyping | Implement Systems | Public Relations Support | systems Development Strategy | Workshops |  Humor


by Kenneth E. Lantz

© 1987 Kenneth E. Lantz


This chapter describes the prototype definition, who should do it, and how it should be done. The chapter first describes what the prototype definition is; next, it makes suggestions on setting up the project team; then, it explains how to develop the prototype definition; finally, it tells how to document the definition, to plan the work, and to secure equipment for prototyping.

Why should you do a prototype definition? The motto might be:

Know what you are going to do before you do it.

The prototype definition will be the basis for building the prototype. Since the prototype is the basis for the system, the prototype definition will be the basis for the system itself.

The prototype will be the vehicle for developing the full requirements for the system, and its definition will be the preliminary requirements for the system. Just as you do not need to develop the full requirements before you build the prototype, you also should not attempt to build the prototype without some kind of a definition of it.

Defining the prototype before building it helps users and Information Systems people think through the basic functions of the system. It is a valuable thing to do, even if the prototype may change considerably when the user actually begins to see its outputs.

One criticism that is often made of prototyping is that the requirements phase of a project using prototyping is too expensive, and keeping the requirements and design phases from running into each other is too hard. If those who are prototyping do not know what is needed for the prototype nor when they may begin building it, they may waste time and resources.

Why define reports and screens on paper? Why not go immediately to layouts or sample reports with a report generator? Often a person from Information Systems must start a user's thinking process by suggesting a layout. But, doing so is difficult for the Information Systems person if he has no idea of the contents, sequence, totaling, and uses of the reports. Even if the users will produce the reports with a report generator, beginning with the report generator now would be premature. You still need a prototype database with some sample data on it, before work with a report generator is meaningful.

Report generators and screen painters will be useful in building the prototype later, but what you need at this point is software for building data dictionaries and structuring databases.

Contents of the Prototype Definition

What will the prototype initially be and look like? It will be a working model of the system that will include the major program modules, the database, the essential screens, the reports, and the interfacing inputs and outputs used to communicate with other systems. It will be a skeletal version of the system and will not contain all the processing and validation rules that the system will finally have.

Table IV-1 lists the contents of the prototype definition. The definition has two parts:

1. what the system should do

2. how it should do it

The logical definition describes what it should do. The physical definition, which some call the physical design, describes how it should do it. Neither definition should be complete and exhaustive, since you should not try to make the initial prototype complete and exhaustive.


Logical Definition

. Reports

. Screens

. Information

. Functions

. Controls

. Interfaces

Physical Definition

. Database

. System Flow

Prototype Definition Contents

The system whose prototype you are defining may be one of the following:

The definitions of both a batch and an on-line system will be similar. The documentation of packages and existing systems should be adequate as a basis. The project team should only need to add definitions for those parts of the enhanced or modified system that are new or different. One exception is when the existing system or package does not have a well-defined database and the new system is a significant modification. Then, you should consider defining the entire database as part of the prototyping effort.

Logical Definition

The logical definition of what the system should do includes a description of the reports and screens the system should produce, the functions it should perform, and the information it should require.


The description of each report should include its purpose, a list of the information elements the report should contain,

the source of the information, how many pages it may contain, the sequence it should be produced in, how it should be totaled, how often the report should be printed, whether special forms should be used, how many copies of it should be produced, and who should receive them. Table IV-2 lists the contents of report descriptions.


. Purpose

. Contents

. Sequence

. Volume

. Source of Information

. Totals

. Frequency

. Distribution

. Special Forms

Report Description


Systems use screens in conversations for entering information and responding to inquiries. The screens include menus that list options, input screens, screens that are partly input and partly output, and screens that display the responses to inquiries. The description of screens should include their purpose, a list of the information elements to be displayed on each screen, the sources of the elements, the sequence in which screens will be displayed, the number of screens that will be entered during a time period, the relationship of different screens in a conversation, and who should be allowed to view the screen. Table IV-3 lists the contents of screen descriptions.


. Purpose

. Contents

. Source of Information

. Volume

. Sequence

. Relationship to Other Screens

. Access

Screen Description


The description of information tells what useable data the system develops and maintains as a database. It should include a description of the information elements and the records which contain them. You should use some sort of automated data dictionary system for maintaining this information. The system may be a purchased package or something that you develop, possibly using a microcomputer DBMS.

The information element definitions you develop for the prototype definition will not be complete and exhaustive, yet you should take great care in developing them. The success of the prototype and the system will depend on whether it is based on a good initial understanding of the information elements. Even though both the users and the Information Systems people may think they understand the information as they begin the definitions, they may learn that they do not. Persevering to produce good definitions willpay dividends for the rest of the system development process.

Table IV-4 lists the contents of a complete information element description and specifies which parts should be done for the prototype definition.



. Element Name Yes

. Element Abbreviation No

. Characteristics Yes

. Element Definition Yes

. Subelements Yes

. Processing Rule Yes

. Alias Names No

. Validation No

. Headings No

. Responsible for Changes No

Information Element Description

The element name is the best name by which the information element is known. Although all the alias names do not need to be found and recorded during this phase, if you know of other names that are used for the element, record them.

The element abbreviation is a short form of the element name that is often used in programs and database definitions.

The characteristics of an element include its size, what kind of characters (alphabetic/numeric/special) it contains, whether it contains any decimals, and whether, if numeric, it is always positive or negative.

The definition of the element is a word description of it. This is similar to a definition in an English language dictionary.

Subelement descriptions, including the positions within the element that they occupy, are important for defining an element. Many elements contain subelements. For example, a telephone number element may consist of an area code, a prefix, a station number, and an extension.

Some elements have a processing rule which tells how to develop or calculate them. A processing rule applies to an element, if the element is always developed or calculated the same way, using the same elements as sources, regardless of what databases or tables it appears on. An example of a processing rule for an amount net pay element would be:

Amount Net Pay = (Sum of all pay and additions) - (Sum of all deductions and reductions)

The validation rules for an element tell what its allowable values are. They are not necessary for the prototype definition, but easily stated ones, such as validate cost center identification against a cost center table, may be helpful.

The headings describe the standard headings to be used for an element on reports and screens. Spending time to develop them for the prototype definition is not advisable, so choose something quickly.

The identification of the organization responsible for changes to the element definition is also a part of the final element definition, but it is not needed for the prototype definition.

Table IV-5 lists the contents of a complete record description and specifies which parts should be done for the prototype definition. The record characteristics describe the record itself. The record contents describe the information elements in the record.

Table IV-6 lists the criteria for defining a record. Adhering to these criteria will help you develop a third normalized form of the record definition. Gane and Sarson provide more information on how to develop this.


Home | Contact Us