Compaq ACMS for OpenVMS
Concepts and Design Guidelines

Previous Contents Index

Chapter 2
ACMS Application Design

This chapter explains how to design a transaction processing application using ACMS. It describes the role of the design process in the overall application development life cycle. The steps in the design process are mapped to the remaining chapters of this manual.

This chapter also describes the documents used to outline the design: the Requirements Specification, Functional Specification, and Programming Specification.

2.1 Understanding the ACMS Application Development Cycle

As an ACMS application designer, you have been presented with the task of creating a TP application to automate a part of your business. This manual offers a design process that gathers and organizes the information needed to create an efficient and effective transaction processing application. The terminology of the design process outlined here is less important than information gathered through that process. Where the terminology is unfamiliar, or the steps seem out of sequence, consider in your own terms the need being addressed. The aim is to create an application design that accurately reflects the business need, and in which all the design implications have been acknowledged and addressed before the application is written.

A complete, logically coherent design for an ACMS application includes descriptions of the following components of the application:

This manual provides you with design guidelines for ensuring that all components work together.


Section 2.2 describes the relationship between application and database design. Although database design is outside of the scope of this manual, it is well-documented in data management product documentation, such as the Rdb documentation.

Section 1.1.3 describes the application development life cycle. Recall that the application development life cycle consists of:

This manual describes the planning and design phase of the application development life cycle. The following documents structure the planning and design phase:

The planning and design phase can also include an optional prototype effort to create simplified models of the application to test the design's structure. This manual does not address prototyping.

Application design is an iterative process. Each time you complete a step in the design process, you must validate that your design still meets your stated goals, which you define during requirements analysis. If not, you may have to modify either your design or your application requirements. Even though you typically cannot begin coding your application until your design is complete, keep in mind that the development process is not linear.

2.2 Relating Application Design and Database Design

Application design and database design are separate but related work. Application design and database design may be done by the same person, or by different people. In either case, although both designs can begin simultaneously, at some point application design must await some of the results of database design.

The design of an ACMS application and its accompanying database begins with the same requirements, which are defined in the Requirements Specification. Therefore, both application and database design must meet the same set of requirements.

Following the requirements analysis phase, database design proceeds to a detailed data analysis to ensure that data descriptions are complete and accurate, and to determine if anticipated business changes warrant modifications to data descriptions. Then, normalization of the database follows. Normalization eliminates data redundancy from the proposed database model. Generally, application design cannot proceed until database normalization is complete.

However, you cannot assume that database design is complete when application design begins; only the preliminary phases of database design precede application design. Once both design processes begin, they are interdependent. To ensure that all the requirements of the application are accounted for, consider the needs of the application design and the database design separately. Then, after each step in the design process, compare the application and database design to ensure that they match.

2.3 Using Software in the Design of ACMS Applications

ACMS design requires you to consider the following software components and products:

You also need to select a CASE environment:

2.4 Identifying the Steps in the ACMS Application Design Process

Table 2-1 summarizes the steps involved in designing an ACMS application, the design document that relates to each step, and the chapters in this book that describe each step. Table 2-2 describes each design document.

Table 2-1 Steps for Designing an ACMS Application
Step Description Design Document Further Information
1 Define or reaffirm business problem that application will solve. Requirements Specification Chapter 3
2 Specify each business function that the application will automate. List distinct activities involved in performing each business function. Requirements Specification Chapter 3
3 Determine requirements, in business terms, for how each business function should be performed. Requirements Specification Chapter 3
4 Determine data entities accessed by each business function. Requirements Specification Chapter 3
5 Write Requirements Specification. Requirements Specification Appendix A
6 (Database designer performs initial database design)    
7 Determine one or more transactions within each business function, and determine functionality used to implement those transactions, including the use of deferred processing and distributed forms processing. Functional Specification Chapter 4
8 Write Functional Specification.

Review Functional Specification with users of the application and members of design team. Refine requirements, if necessary.

Functional Specification Appendix B
9 Map each business function to one or more ACMS tasks. Programming Specification Chapter 5
10 Design task definitions. Programming Specification Chapter 6
11 Design code for step procedures. Programming Specification Chapter 7
12 Design user interface. Programming Specification Chapter 8
13 Design overall application structure, including task groups. Programming Specification Chapter 9
14 Write Programming Specification Programming Specification Appendix C

Table 2-2 Design Documentation for an ACMS Application
Name Description
Requirements Specification Specifies the business need and the requirements to solve that business need. The Requirements Specification is high level and can be produced in a limited time frame. It does not contain specific design details unless these are considered to be a business requirement. It bridges that gap between a customer's business need and the Functional Specification and Programming Specification.
Functional Specification Specifies, in non-technical terms, what the solution does for the customer. It is a detailed specification of the functionality to be addressed by the solution. This document defines what functions the system will be capable of performing. It is the blueprint for the subsequent design and programming of the system. To write this, the designer must understand the functionality available in forms, databases, ACMS, and other software and hardware.
Programming Specification Describes a design that provides the proposed functionality and meets the business requirements. Some of the activities can be included here instead of in the Functional Specification.

Chapter 3
Creating a Requirements Specification

This chapter offers guidelines for describing the business problem that your ACMS application is going to solve. It illustrates how to break the business problem into discrete segments of work. It also describes characteristics of these discrete segments that are important to consider when designing an efficient application. Use these guidelines to create a Requirements Specification in which you:

3.1 Defining the Business Problem

Before designing an application, you must analyze the business problem and produce a Requirements Specification that describes the business need addressed by the application. The goal of the Requirements Specification is to define, in terms of the business and at a high level of detail, what the application must accomplish.

For example, the work of the AVERTZ car rental company is to rent cars. For AVERTZ, the business problem is to create a TP system that allows car rental agents interactively to display, enter, and update data stored in a car rental database when serving customers. A description of the business problem includes not only a description of the need, but also the goals with related measurements.

The Requirements Specification also defines constraints on an application that are independent of the step-by-step analysis of the work being performed. Constraint information includes who will use the application, how frequently the users will access the application, and what users will be granted access to different parts of the application. It also includes data security requirements, minimum acceptable performance, and time and cost for delivery of the working application. Section 3.3 describes how to collect these additional requirements.

Appendix A contains a sample template for a Requirements Specification.

3.2 Analyzing the Work Requirements

This manual analyzes the work done by AVERTZ employees by breaking down the work into the following hierarchy:


You might describe your business in terms other than "business area", "business function", and "business activities". Whatever the name, the aim is to move from the general (business area) to the specific (business activities). For consistency, this book will use only those terms.

The following sections describe a requirements analysis based on the description of business areas, business functions, and business activities.

3.2.1 Business Areas

Most businesses are divided into areas, departments, or functions. The requirements for a TP system are the sum total of the requirements for each business area. Each business area collects and maintains data on its own and shares some of this data with other areas of the business. Derive an application requirements list by studying current business practices and questioning department managers and prospective users of the system.

Most areas of the AVERTZ business support its primary business function, which is renting cars. Table 3-1 lists the AVERTZ business areas that support renting of cars.

Table 3-1 Business Areas in AVERTZ
Business Area  
Reservation processing  
Site management  
Car information  
Customer accounts  

Note that the AVERTZ sample application handles only the reservation processing business area of the AVERTZ company.

3.2.2 Business Functions

This section describes the business functions that comprise the reservation processing area of the AVERTZ business.

Car rental agents enter or modify reservations at the central office or at any AVERTZ site. This business function has the following responsibilities:

3.2.3 Analyzing Business Activities

Each business function consists of a set of business activities. These activities are the logical transactions that the application system must perform and that the database must support. To determine database and application requirements, first develop a description of each discrete business function. Then list activities that users perform to carry out each business function.

Table 3-2 lists the business areas for the AVERTZ company, and business functions for each of those areas. Table 3-3 lists the business functions in the reservation processing area of AVERTZ's business and lists the business activities required to perform each function.

Table 3-2 Business Areas and Business Functions in AVERTZ
Business Areas Business Functions Within Areas
Reservation processing Reserve a car
  Check out a car
  Check in a car
Site management Add new sites
  List site directory
  Create car/site report
Car information Add new car information
  Create car history report
Customer accounts Create customer report

Table 3-3 Business Functions and Activities in AVERTZ Reservation Processing Area
Business Function Within Area   Activities Within Business Function
Reserve a car 1 Enter any of the following information:
Customer ID
Customer name
Site ID
City name
Rental dates
Car type
  2 If no site ID is supplied, and there is more than one site in the city, choose from a list of sites.
  3 Once site ID is identified, if multiple customers have the same name, choose from a list of customers.
  4 If it's a new customer, add information. If it's an existing customer, update information, if necessary.
  5 Provide a reservation number and ask if the customer wants to check out car.
  6 If checkout is requested at the time of the reservation, begin the checkout by finding if a car is available (go to step 4 below).
Check out a car 1 For a customer who made a reservation previously and did not checkout a car then, enter either the customer ID or the reservation ID, or both.
  2 If the customer has multiple reservations, choose from a list of that customer's reservations.
  3 Once a single reservation has been identified, update the customer and reservation information, if necessary.
  4 Once the customer and the reservation information is complete (either from an on-the-spot reservation and checkout, or when the customer comes in some time after reservation to check out the car), ask for cars of the specified type.
  5 If no cars of the specified type are available, select a more expensive type.
  6 Choose from a list of cars of the specified type.
  7 Allow the user to check out the car, cancel the reservation, or quit without canceling the reservation.
Check in a car 1 Enter either the reservation ID or the customer ID, or both.
  2 If the customer has multiple reservations, choose from a list of that customer's reservations.
  3 Once a single reservation has been identified, update the customer and reservation information, if necessary.
  4 Enter the new odometer and gas gauge readings.
  5 Compute the customer's bill.
  6 Update the reservation record, reset car availability flag and the actual odometer reading, and the return date of the car.

Previous Next Contents Index