Representing open requirements with a fragment-based specification

724 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 23, NO. 3, MAYIJUNE 1993

Representing Open Requirements with a Fragment-Based Specification

Bruce I. Blum

Abstruct- The paper describes and evaluates an alternative representation scheme for software applications in which the requirements are poorly understood or dynamic (Le., open). The discussion begins with a classification of requirements specification properties and their relationship to the software process. Emphasis is placed on the representation schemes that are most appropriate for projects with open requirements in a flexible development setting. Fragment-based specifications, which capture a conceptual model of the product under development, are recommended for such applications. The paper describes an environment, in production use since 1980, that employs this form of specification. Evaluations of the environment’s economic benefit and of the specification scheme’s properties follow. A final section contains observations about the nature of future software applications and the environments necessary to support their development and maintenance.

I. INTRODUCTION

N HER DESCRIPTION of an engineering discipline for I software, Shaw states that any definition of engineering capturing the sense of custom usage includes the clauses, “Creating cost-effective solutions . . . to practical problems . . . by applying scientific knowledge . . . to building things . . . in the service of mankind” [56]. Examples of engineering disci- ples include systems engineering (where the practical problems relate to the construction of a system, often composed of different types of components) and software engineering (where the problem domain is limited to a system’s software components).

All engineering processes share common or similar activities. In response to some practical problem, the process first elicits a statement of the product goals (e.g., the requirements), proceeds to establish how those goals can be met (Le., the product design), next creates the product, and finally tests and-if successful-uses the product. The character of each step is determined by the engineering discipline and the product. For example, when building a bridge, the test is a certification activity. It is the bridge design that is tested for correctness. This testing is made possible by the years of experience in building bridges; the extensive testing of the design is motivated by the prohibitive costs for correction once fabrication is underway.

Manuscript received November 6, 1992; revised January 22, 1993. This work was supported in part by the U. S. Navy, Space and Naval Warfare Sys- tems Command (SPAWAR) under contract N00039-91-C-0001, task VMAR9 with the office of Naval Research (ONR) and the Naval Surface Warfare Center (NSWC).

The author is with Johns Hopkins University/Applied Physics Laboratory, Laurel, MD 20723-6099.

IEEE Log Number 9209623.

The flow for software development has been modeled after the flow used in systems engineering [12]. In most models of the software process, the activities are divided into two distinct phases. The first defines a response to the domain problem in the form of a software requirements specification, and the second transforms that specification into an efficient implementation. But there are distinct differences between hardware and software [13], and it is appropriate to reexamine the role of the requirements specification in the software process. The benefits of such an analysis can extend far beyond the immediate needs of software engineers. In reality, software is a design: a detailed specification for sequencing the computer’s operations. Consequently, improvements in the methods for developing software can be transferred to the design of automatically fabricated hardware (e.g., VLSI chips and robot-built products).

This paper narrows its examination of the requirements specification to a specific class of software application: that for which the needs are poorly understood but where the technology available for realizing a response is relatively mature. The paper opens with a survey section that establishes a framework for the problem being addressed. The next section describes the role of the requirements specification in an environment developed for this particular class of application. The following section evaluates experience with this environment and its requirements specification. A final section offers some concluding observations.

11. BACKGROUND As a consequence of centuries of product fabrication, en-

gineers have come to accept a process model based on two discrete tasks. First the sponsors design a solution to some real-world problem, and then the engineers design a product to implement that solution. We have come to call the solution to the real-world problem a requirements specification; other fields rely on equivalent milestones (e.g., the researcher’s hypothesis and the architect’s plans). The thesis of this paper is that the software engineer’s view of the requirements specification is an artifact of engineering’s experience with hardware systems; the abandonment of that view permits the software engineer to explore alternative specification concepts that exploit software’s unique properties [ 131.

The description and evaluation of an environment that implements one such alternative provides the body of the paper. The purpose of this section is to establish a philosophic framework for the discussion that follows. It opens with a categorization of the different types of requirements. Next, a

001&9472/93$03.00 0 1993 IEEE

BLUM: REPRESENTING OPEN REQUIREMENTS WITH A FRAGMENT-BASED SPECIFICATION 725

description of the software process examines the various roles of requirements in a software development. The final section lays the foundation for the requirements representation used by the environment to be described and evaluated.

A. Requirement Classification Requirements specifications are not homogeneous, and they

may be organized in a variety of ways. This section identifies three requirements classification schemes. These schemes overlap, and there may be additional categorizations. The existence of so many subgroupings implies that any analysis of the role of requirements specifications should be restricted to well-defined classes.

The most common division of requirements is with respect to the system properties they specify. Two categories normally are identified.

Functional: These define the functions that the product is to provide. With software, this is sometimes referred to as the behavior of the specification, which can be specified formally. (In systems engineering, behavior takes on a slightly different meaning.) The functional requirements establish the objectives that the product is to meet, and with software, they can be considered in a logical context.

Nonfunctional: These define constraints that the product must satisfy. With software, they are descriptive properties of the completed system that can be evaluated (e.g., processing time, resource utilization). The software engineer can model the nonfunctional properties of a system, but from a software perspective, the nonfunctional requirements are extralogical (Le., they are not subject to the same logical inspection as is the system’s behavior).

The software requirements specification establishes a set of implementations that will respond to a particular need. It employs generality at the expense of efficiency. The design reduces that generality until a single product, optimized for a particular environment, exists [65]. Logic may be used to ensure that the design decisions are correct with respect to the functional requirements; because the nonfunctional requirements are extralogical, the software engineer must rely on analytic tools to predict or assess their satisfaction.

A second classification scheme organizes the requirements according to their relative importance. Three levels are defined.

Essential: These requirements specify all the properties of the target system that must be delivered for the system to be acceptable. The essential requirements are never complete [44]; completeness would overspecify and thereby constrain the freedom of design.

Derived: These specify system features derived from the essential requirements. The derived requirements are never explicitly included in the requirements specification, but there is seldom a distinct boundary between the essential and derived requirements.

Implicit: These requirements are assumed to be a byproduct of “sound engineering practice.” Because there are too many such practices to specify explicitly, only those that demand particular attention are elevated to the level of essential requirements.

In a sense, the implicit requirements exist before the project is initiated, the essential requirements constitute those called out in the specification, and the derived requirements surface during the design activity. To illustrate this stratificafion, consider an accounting system with the essential requirement that it print out tax forms. The specification of the particular form formats might be a derived requirement, and the fact that an audit trail and recovery procedures are necessary might be an implicit requirement. Depending on the situation, however, any of these derived or implicit requirements could be included in the essential category. The point is that not all requirements are essential. Moreover, the selection of which requirements are to be considered essential is a subjective matter. In fact, the decision often is affected by the state of understanding at the time the specification is documented.

The final categorization scheme qualifies the character of each requirement. Three types of requirement are identified.

Closed: Closed requirements are well defined and stable. Often there is an existing domain notation that can be used to express the requirements. For example, mathematical notation is used in engineering applications. Most hardware products expect closed requirements before initiating the final construction. Because of the precision of the specification, the greatest uncertainty normally is with respect to the delivered product’s ability to satisfy its requirements.

Abstract: Abstract requirements model properties and products that have no concrete realization; the concept is expressed by the notation. For example, there is no external reality for “safety” or “software security.” These concepts (which may express functional or nonfunctional properties) must be modeled abstractly so that analysts can reason about them. The greatest uncertainties are in how effectively the representation scheme captures the concept being modeled and how thoroughly the model is investigated.

Open: Open requirements are poorly understood and dynamic. Often these requirements specify product properties that are routinely achieved with the current practice. A typical example is the naive use of an existing technology in a new domain. With open requirements, the greatest uncertainty is in the ability of the specified product to meet expectations in a real-world setting.

Few applications fall into just one category, and most complex products contain components with closed, abstract, and open requirements.

In the traditional requirements specification, there is a clear distinction between the functional and nonfunctional requirements. But the specification identifies only the essential requirements and makes no distinctions regarding the character of the individual requirements (i.e., all functional requirements are specified as if they were closed). Yet, the distinction between the essential and derived or implicit requirements is a matter of subjective choice; it is determined more by project- level dynamics than by product-specific needs. Furthermore, the differences in character between a closed and an open requirement are so great, that few methods and process models are satisfactory for both. Thus, a serious analysis of requirements specifications must begin by removing the artificial distinctions among the essential, derived, and implicit require-

726

Appkatbn

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 23, NO. 3, MAYIJUNE 1993

Conceptual Models

I I

Fig. 1. The essential software process.

ments and, at the same time, differentiating between open and closed requirements. As the title of this paper suggests, the focus here is on open requirements. Because applications with open requirements normally rely on a mature technology, they tend to have few critical nonfunctional requirements. There- fore, the following discussion will emphasize open functional requirements, without regard to their relative importance.

B. The Software Process

The discussion of requirements in this paper is limited to their role in software engineering, which I define as the creation of effective software solutions to application domain problems through the use of computer technology guided by its associated scientific base. The software process is a sequence of software engineering activities, each of which begins with the identification of a need and concludes with the delivery of a software product that responds effectively to that need. Lehman observes that each response alters the original need, and-therefore-product installation generates requests for product modification [43]. Thus, the software process is iterative; it begins when a need is identified for which no partial software response exists, and it terminates when the need ceases to exist and/or the software product is retired. Fig. 1 illustrates one cycle in this essential software process [12]. Here, essential refers to the essence of the software process as that term is used in the subtitle of “No Silver Bullet: Essence and Accidents of Software Engineering” [23].

The figure depicts two domains: the application domain, in which the need exists, and the implementation domain, in which the software response to the need operates. ’ b o categories of modeling are identified. The conceptual models describe the need and the proposed response from the perspective of the application domain. The models may use domain formalisms, but from the perspective of the software product- the conceptual models are descriptive and not prescriptive. The formal models are formal in the computer science sense; they specify the essential features of the software product that will respond to the need. Notice that the conceptual and formal modeling lines do not intersect. Conceptual modeling always begins in the application domain and cannot result in the specification of a software product. Formal modeling must begin after a conceptual model exists; the most complete formal model is the implementation. The objective of the conceptual model is to record the design of a solution to a real-world problem, and the objective of the formal model is specify that solution and the design of a product that realizes it.

The process shown in Fig. 1 normally is decomposed into three transformations.

From the need identified in an application domain to the conceptual model of a response to that need. For open

problems, there will be many possible interpretations of the need and many conceptual models for each interpretation.

From the conceptual model that describes the response to the need to a formal model of the essential properties of the software product that realizes the response. For most problems, many different formal models can express the intent of the conceptual model.

From the formal model to its implementation as a software product. Again, there are many different implementations that will be correct with respect to the formal model. The first two transformations depend heavily on applica-

tion domain understanding, whereas the third transformation operates almost exclusively in the domain of computer science.

The essential software process does not identify a requirement (or requirements specification); it only speaks of a need and a software response to that need. Moreover, the activities of conceptual and formal modeling overlap. This is consistent with studies that show the software design process to contain parallel activities [26] that are addressed opportunisticly [37]. The management of the process, however, relies on a discrete model [12] with measurable criteria for tracking [29]. The waterfall model [53] and some of its variants (e.g., [20]) often are used to structure and control the process. These management models introduce a need for identifiable documents that serve as project schedule events. In this context, the requirements specification, which serves as a contract between the sponsor and the developer, becomes a key document.

In addition to this legalistic role, the requirements specification serves as the first formal step in the evolution from a subjective identification of a need to the delivery of a software product. Therefore, the requirements specification serves as a watershed in the transition from the structuring of the problem (e.g., [58]) to the delivery of an implemented solution. In theory, the earlier a formal model exists, the more effective will be the control over the product’s quality. The justification for this assertion is that correctness is always with respect to a specification. Without a specification, there are no criteria for assessing correctness, and the designers can only apply domain formalisms to refute validity [51].

Although the essential software process does not identify any need for requirements specifications, the software engineering community accepts them as essential because they are mandatory for establishing correctness and they are considered necessary for project management. And here is the central dilemma for projects with open requirements. If the requirements are open, then there is little confidence in the specification of what is to be developed; but without the requirements, implementation cannot begin.

Software engineers resolve this conflict in one of three ways. The first alternative is to structure the project using incremental development. The product is layered into builds that permit the evolutionary refinement of earlier concepts [35], [47]. In Brooks’s words, “Grow, don’t build systems” [23]. A second technique is to use prototypes to resolve uncertainties prior to


the preparation of a specification. With the classic, throw-away prototype, some portion of the requirements analysis budget is devoted to prototypes, and the lessons learned from those prototypes are documented as requirements; the prototype then is discarded [36]. In the spiral model, prototyping is integrated into a modification of the waterfall flow, and a cyclic progression is used to produce the requirements specification [20]. These two methods are not independent and may be combined [54].

A third technique, which largely is restricted to research domains, uses a special environment to experiment with the specification. For example, the operational approach begins with a model of the intended product @e., the response to the need) and uses properties of these specifications to reason about the product’s behavior [64]. Balzer uses an executable specification, which serves as a prototype, to establish what the product is to do. A separate optimizing step improves performance, and all maintenance is performed at the specification level [2]. Simulations may be substituted for prototypes. Megaprogramming reuses simulation components to support experiment with the specification [21], [62], and Hare1 uses an environment that relies on simulations to develop and refine requirements [38].

In this discussion of requirements, there has been no men- tion of the techniques used for developing and expressing the requirements. The topic of requirements analysis methods has an extensive literature. There are a comprehensive survey [28], collections of papers [30], [59], and several taxonomies of methods [16], [27]. Indeed, a discipline of requirements engineering is emerging [34]. But this section is concerned with a normative model for the analysis of open requirements. In this context, descriptions of how that analysis presently is conducted can obscure rather than inform. This is not, of course, to suggest that our experience in requirements analysis is inappropriate for these applications. Many of the methods discussed in the referenced sources are responses to the problems identified here. For instance, Yeh describes systems development as a “wicked problem” and then proposes an alternative process model for controlling some of the side effects of what here are referred to as open requirements [63]. Thus, there are different interpretations of a common understanding, each of which leads to an alternative set of solutions. However, a more detailed examination of, for example, Yeh’s ideas would digress from the central focus of this paper, which is the description and evaluation of a specific representation scheme for open requirements. This paper establishes a philosophical foundation for a new approach to requirements analysis and software development; its presentation is self-contained and independent of the methods we now use (or propose to use) in responding to this particular challenge.

In summary, although there are justifications for a requirements specification, such a document is not essential to the software process. It is needed only for the management of the process. For projects with an informal organization (e.g., inhouse developments and level-of-effort support), the management role of the specification diminishes. When there are open requirements without the need for a contractual specification, the designers may favor the specification of a

system that is known to work (i.e., an as-built specification) rather than the specification of an unbuilt, and potentially invalid, system (Le., a to-be-built specification). Clearly, the as-built specification is not possible in many organizational and contractual settings, and the traditional role of the requirements specification will continue. Yet for situations in which there are open requirements and flexible management controls, the as-built specification can be viewed as the complete closure of the open requirements (i.e., the specification is extended to include all derived requirements until it becomes isomorphic to the implementation).

C. Requirements Representation The two previous sections examined the nature of re-

quirements and the role of the requirements specification in the software process. This section completes the background discussion by examining how requirements can be represented. The scope is limited to open requirements (of all importance levels) without regard to any management concerns. In the earlier analysis, the software process is described as a problem- solving activity, and the requirements specification is depicted as an evolving body of knowledge about the problem’s solution. That is, the specification initially describes how a software-supported system can provide a solution to some domain problem; when it is augmented by all the derived details, it becomes the as-built specification of that product. Although unconventional, this description of a requirement is consistent with the essential software process model flow depicted in Fig. 1.

Simon observes that . . . solving a problem simply means representing it so as to make the solution transparent. If the problem solving could actually be organized in these terms, the issue of representation would indeed become central. [57, p. 1531

A reasonable research goal, therefore, is the development of a requirements representation scheme that captures everything known about the desired solution and that also can be used for the automatic generation of efficient programs. Fourth- generation language (4GL) systems provide precisely this sort of facility. Unfortunately, 4GL applications often are characterized as being relatively simple, not very efficient, and potentially difficult to maintain. What is desired, of course, is a representation scheme that will permit an environment to deal with arbitrary complexity (within a mature technology) and produce efficient implementations that are highly maintainable.

The environment to be described in the following section seeks to achieve this goal by representing how a computer- supported system responds to the application domain needs. This is a very different goal from that of modeling the application domain [52] or of assisting the activities involved in a traditional product implementation [46]. With the approach to be presented here, the items to be represented are the functional (and nonfunctional) requirements to be satisfied by the delivered system. Because the environment is intended for use with open requirements, its representation scheme must permit the full specification of well-understood concepts within a framework of incompleteness and change.

728 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 23, NO. 3, MAYfJUNE 1993

Because the environment can make extensive use of computer support, the scheme also should exploit those special features of software that are made possible through automation.

There are several approaches to organizing a representation scheme. A formal, mathematical notation may be used. The difficulties with this orientation are that it is top down and requires stability; therefore, it is not considered suitable for open requirements. The selected representation scheme, however, must itself be subject to well-understood mathematical principles. That is, the representation scheme must be a formal mechanism for representing concepts that, themselves, cannot be effectively described mathematically. In effect, this is an example of information hiding in which one hides from the analyst the details of specification operation and from the environment designer the details of specification use [50].

Another representation method models the implementation as components to be integrated [3], [62]. This approach is rejected because it tends to focus on the solution space rather than the domain-specific problem space. By using information hiding, however, it is possible to transform external statements about functionality into internal commands for component integration. A third common software engineering representation technique employs diagrams. Most diagramming tools favor comprehension over precision, and few can be used formally. (Notable exceptions include the diagrams in JSD [24] and STATEMATE [39]; as a less formal exception, note that some entity-relationships diagrams can be transformed into a data model specification [25].) Nevertheless, there are inherent difficulties in the management of large diagrams, the ability to display hidden associations, and the power to resolve ambiguity. Thus, diagrams are rejected as a primary notation, but the environment’s use of visualization techniques for specification perusal and understanding is encouraged.

The scheme chosen for this environment relies on a database to integrate the concepts within the specification. These concepts are stored as fragments, and they are unified within a holistic structure. Fragments can be composed of fragments or reduced to fragments and primitive concepts. It that sense, the requirements specification exhibits a structure similar to that of a human memory model with chunks (fragments) and a schema (holistic structure). The obvious advantage of this fragment-based organization is that it is highly adaptable, it reduces redundancy, it offers multiple levels of granularity, and it permits consistent concept building. The major disadvantage of a fragment-based organization is that it cannot exist outside its environment, thereby creating problems in exchange, standardization, and environment evolution.

Because of the extensive experience with traditional notions of a requirements specification, the concept of a fragment- based specification is difficult to convey. The next section describes an environment that implements such a scheme, and the following section evaluates a decade of experience with the use of that scheme in real-world settings.

111. THE TEDIUM ENVIRONMENT

This section describes an environment for developing and maintaining interactive information systems with open require-

ments. As defined by the software engineering hierarchy [48], an environment is an integrated collection of tools, used by a compatible set of methods and practices in support of a specific process model. That is, the environment always must be customized to a particular software process model. Most software engineering environments (SEE) are designed to support variations of the waterfall model, and most computer- aided software engineering (CASE) tools are designed to be integrated into a SEE. The objectives of the environment to be presented here differs from the CASE/SEE approach in that it is designed to provide comprehensive automated support for the essential software process shown in Fig. 1.

TEDIUM,@ the environment to be described, concentrates on supporting the conceptual modeling activity. It uses a formal specification notation that permits its users (called designers) to record concepts related to the use of the target system within the real-world setting. That is, the TEDIUM designers are responsible for designing a software response to an application domain need; they are not concerned with the traditional software design task of producing an implementation that satisfies a given specification. TEDIUM begins with an open requirement, and it produces an as- built specification. Not only is the role of the requirement different in TEDIUM, so too is its form. Because the intent is to capture concepts, the TEDIUM specification is organized around conceptual fragments. Fragments are integrated within the TEDIUM specification, and fragments may be composed into fragments of higher granularity.

This fragment-based specification is maintained as an application database (ADB), whose goal is to capture everything known about the application being developed or maintained. The ADB constitutes a unified specification of the application (i.e., its conceptual model); the product (programs and documentation) is generated from the ADB. The concepts modeled in the ADB relate to how a software product can respond to the identified need. This is quite different from the knowledge engineer’s objective of representing the knowledge used by the domain specialist in the execution of his task. For example, when using TEDIUM to build a clinical information system, the designer identifies the kinds of information used by the organization and then builds tools that provide the necessary access and computations. The TEDIUM designer does not model the medical rationale employed by the system’s users (i.e., medical knowledge); he focuses on what is needed to support the medical staff, when it is needed, and how it should be managed and presented.

The conceptual model within the ADB isolates the designer from implementation details. Using the principle of cognitive fit [60], the designer is provided tools that permit him to reason about software responses to a need. Using the principle of information hiding, the designer is shielded from information about the implementation’s design. Two preconditions make this form of information hiding possible. First, the conceptual model is represented formally, so that domain- oriented actions are described precisely and are in a form that permits automated inference and manipulation. Second, the

@TEDIUM is a registered trademark of Tedius Enterprises, Inc.


technology of interactive information systems is sufficiently well understood to permit the automatic transformation of concepts in the fragment-based model into implementation units that perform efficiently. Thus, the designer need not consider implementation issues except for those particular areas in which nonfunctional requirements are affected.

To support its development paradigm, TEDIUM presents the designer a comprehensive interface that permits him to peruse and modify the contents of the ADB, to generate programs that express the behaviors specified in the ADB, and to experiment with intermediate designs. The technique is similar to that described above as the operational approach. The major difference is that the objective of most environments employing the operational approach is the validation of a requirements specification, whereas with TEDIUM the specification is seen as an evolving description of the as- built application. To support the transformation from the conceptual model embedded in the ADB into a deliverable implementation, TEDIUM relies on three knowledge domains.

Application knowledge. This is knowledge about the particular application under development. It represents a description and specification of the application, and it is maintained in the ADB. This is the only knowledge visible to the designer.

Application-class knowledge: This is knowledge about all applications of a specific class. Examples in the class of interactive information systems are the validation of all inputs, the availability of help for all interactions, and the assurance of referential integrity. Other application classes (e.g., real-time systems) will be represented by different knowledge.

Sofhvare-tool knowledge. This is the application-independent knowledge related to computer technology. It includes knowledge of how to translate specifications into implementations, how to improve performance, how to manage knowledge and data, and how to support the user interface. It is what Neighbors refers to as model domains [49].

All application knowledge is retained in the ADB. The application-class knowledge is stored in a system style that establishes the implicit and default behaviors for every program to be generated. The software-tool knowledge is used to build the generators (one for programs, the other for documentation). Each generated program provides the features explicitly specified in the ADB plus all the features implicitly identified in the system style. Thus, every generated program is functionally complete in that 1) it performs every function demanded of it and 2) it has every characteristic expected of programs of this particular application class. Because the technology is relatively mature, all the programs created by the generator are both final (i.e., not subject to subsequent refinement) and efficient. Consequently, every generated program is of production quality (i.e., it is functionally complete, final, and efficient).

By freeing the designer from the details of implementation, the design task reduces to the iteration of two activities. First the designer models the software application in the ADB, and then he exercises that model with the generated programs. By maintaining a unified and closed conceptual model, all of the generated programs will be correct with respect to the conceptual model. Thus, the designer concentrates solely

TEDIUM interlace

. Fig. 2. Block diagram of TEDIUM.

on establishing the validity of that conceptual model. Once the model behaves as desired, the programs are available for production use. Normally the programs are exercised in an interpretative environment, and the accepted programs are regenerated for use in some other language for a target machine.' Fig. 2 presents a block diagram of TEDIUM.

Because the ADB is intended to retain everything known about an application, it is organized into subjective (informal) and objective (formal) fragments. Subjective material is used to explain and reduce detail, but it may be invalid or out of date. Objective material is always current and accurate, but it may present too much detail. Thus, the ADB maintains both categories of information. The fragments are linked within an application and shared throughout the conceptual model. The subjective fragments normally consist of descriptive text. Some subjective fragments define a structure that highlights important concepts. The objective fragments use a formal notation, and much of the information in a fragment is derived by inference from other fragment specifications. Consequently, much of the meaning captured by a fragment is lost when the fragment is removed from its ADB context. To aid the designer in navigating through the ADB, there is a window into design

For an interactive information system, two categories of

Data Model (schema): This includes the definitions of relations (called tables), relationships, attributes (called elements), and structures (compositions of relations). The schema used in the operational version of TEDIUM is described in [9], and the schema currently under development is presented in [lo], [17]. Programs: There are two types of program specification: procedural and declarative. All declarative specifications allow selected defaults to be overwritten by procedural commands. For a more complete discussion, see [9],

~ 4 1 .

objective fragment suffice.'

~ 7 1 . This statement is a little misleading. There are two versions of TEDIUM.

Version M1 is the environment that has been in use since 1980; it generates programs only in one language. Version T1 is under development hut not yet in operation; it will generate programs in several target languages.

'For other classes of application, additional categories may be necessary. For example, the class of real-time system may need specialized fragments to describe external interface and timing constraints.

_.-- I

730 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 23, NO. 3, MAY/JUNE 1993

These fragments are built from finer grain fragments, and they, in turn, may be organized to produce other fragments.

The organization of the ADB conceptual model takes advantage of the holistic and unifying facilities of an automated database. Because this approach is foreign to most experience, some of the principles can best be illustrated by means of an example. In this illustration, easily understood phrases substitute for the equivalent TEDIUM notation. The example builds on some experience at the Johns Hopkins Oncology Center. We assume that a baseline clinical information system exists and that the need for an appointment system has been recognized. Here is how a TEDIUM designer might respond to that need. He would begin with an analysis of the problem domain to gain a better understanding of the need. In this example, he would find that the Oncology Center has several outpatient clinics and that physicians and patients may be associated with more than one clinic. It is required that an appointment system produce clinic lists, physician schedules, and a list of appointments for each patient (several may be scheduled). The baseline ADB already has definitions for physicians (physician id and name) and patients (history number and name). These are the essential (if over- simplified) requirements, and the specification process may commence.

Beginning with the data model, there is a need for a list of clinics (that uses clinic name as a key) with a short description of when each clinic is open. (Eventually, the clinic schedule model should be formalized to verify that all appointments are made during valid clinic hours.) The appointment model has three external views for its internal representation:

Clinics have appointments, and they must be sorted by day and hour.

Physicians have appointments, and they must be sorted by day, clinic, and hour.

Patients have appointments, and they must be sorted by day and hour.

From this it is clear that each appointment must contain a clinic name, physician id, patient history number, date, time, and some other information about the appointment (e.g., tests scheduled). These attributes can be used to access other information (such as patient diagnosis) included in the schedule listings.

The next step is to produce the schedule listings. Fig. 3 illustrates how a clinical schedule listing program might be specified. This illustration uses a procedural definition that might be specified more effectively by painting a screen with the desired output format. The goal is to provide an expressive description of the response to the need, and there are many alternative styles from which to choose. Nevertheless, despite its procedural structure, the specification avoids implementation details.

Continuing with this example, suppose the fourth line in Fig. 3 were altered to read,

For each day in the clinic schedule between DATE1 and DATE2

This is how to specify a program that accepts values for DATEl and DATE2 and then runs CLINIC-SCHEDULE as a background task. First DATE1 and DATE2 are defined to be

For each clinic in the clinic rchcduk

Head a DCW page for thb clinic with the date of the Ihthg

For each day in the c h i c rheduk

Set upsdayheding

For cach hour in the clinic rchcdule

End

End

End

EndcLlNIc_scHEDuLE

Fig. 3. Sample specification fora clinic schedule.

of type date; this ensures that only valid dates will be accepted as inputs. The specification might be as follows. Program RUN-CLINIC-SCHEDULE

Write “Enter the date range” Input Input DATEl

If DATEl is blank, assign DATEl=today Input DATE2 If DATE2 is blank, assign DATE2=large date If DATE1 > DATE5 write “Start date is greater than

the stop date” resume processing at Input Background job CLINICSCHEDULE(DATE1,

DATE2) End RUN-CLINIC-SCHEDULE

Because this program specifies a procedure, its form is procedural. Some tasks, however, can be described declaratively. For instance, the functions of a menu can be specified as a set of 3-tup1es7

<label,command,action>. Thus, to invoke this new program from the appointment

menu with the command “LC,” the appointment menu specification might be edited by inserting the 3-tuple7

<List the Clinic Schedule, LC, RUN-CLINIC-

Naturally, the TEDIUM interface hides the internal form of the specification and presents a view that is appropriate for describing the concept being specified. Internally, the ADB contains fragments that define the date type, the format for the clinic name, the text to be used in response to a user query about clinics, the structure associating other fragments with the clinic name, and the programs that access the clinic name. Because this level of fragmentation is required by only the program and document generators, it is hidden from the designer. However, everything of interest to the designer is available through the window into design in a form that expresses domain concepts without the distraction of implementation details.

Although this example was intended only to show how the TEDIUM specifications appear to the designers, its simple specification can be expanded into a real appointment system

SCHEDULE>.

BLUM REPRESENTING OPEN REQUIREMENTS WITH A FRAGMENT-BASED SPECIFICATION 731

that meets its users’ diverse need. For instance, once the appointments have been defined and the basic listing produced, the designers and users will begin to address secondary issues. Because physicians are not always available, a physician schedule is necessary to avoid the scheduling of appointments for absent physicians. This entails the rescheduling of patients (when the visit date is not critical) or of other physicians (who will provide coverage for the absent physician). The basic system may be extended to schedule the tests to be performed before the patient is seen by the physician, and the fact that these tests were performed can be linked to the billing system. Visits with other health care providers can be added, and special information useful for outpatient chemotherapy or radiation therapy can be included. (Opening the door to supporting radiation therapy introduces a host of new requirements.)

Thus, the appointment system, which began with a modest statement of need, illustrates how TEDIUM operates within the dynamics of an open requirement. As responses are generated, new needs are identified. The designers can respond to these changing needs because they always work with a conceptual model @e., the ADB contents) that represents the current requirements. They adapt the specification to meet the users’ needs, and the specification always describes the as- built application. To perform effectively, the designers must know the problem domain (e.g., how the Oncology Center operates) and the tools they use (e.g., TEDIUM). But they write no specifications that they cannot test, and they need never produce designs or code from formal specifications. Indeed, the very fact that the designers use a fragment-based specification is hidden from them.

Iv. A N EVALUATION OF TEDIUM

Every evaluation must be with respect to some criteria. Typically, a development begins with an identification of the expected outcomes: the product’s evaluation criteria. Often standards exist that permit the comparison of alternatives (e.g., productivity measured in cost per line of delivered code, reliability measured in MTBF). These evaluation standards may be absent, however, when a new class of product is developed. In such situations, the evaluator must first justify a set of evaluation criteria, and then analyze how well the product satisfies those criteria. The evaluation of TEDIUM in the context of an alternative paradigm has been the topic of this type of analysis [6], [9], [ll], and this section extends the same analytic approach to the evaluation of the fragment- based specifications used by TEDIUM. First the evaluation criteria are justified, and then data from TEDIUM projects are examined with respect to those criteria.

The analysis is divided into two parts. It begins with a brief evaluation of TEDIUM from the perspective of cost effectiveness, and the “value” of TEDIUM is demonstrated. Once TEDIUM is shown to be a viable production-quality environment, its specification scheme is examined.

A. Cost Effectiveness of TEDIUM The broad goals of a cost-benefit assessment “are to provide

procedures for the estimation and evaluation of the benefits

and costs associated with alternative courses of action” [55, p. 4551. It might seem to follow that the criteria for esti- mating the casts and benefits of an alternative development environment are straightforward: compute the ratio of the cost to install the environment and the savings resulting from its use. Unfortunately, the problem is not as simple as it may seem. The TEDIUM environment alters the development process, thereby enabling outcomes that otherwise would not be possible. By way of analogy, in the 1960s the Sequential Multiple Analyzer dramatically affected the volume of tests that could be processed in a medical laboratory. Where Mount Sinai Hospital in New York performed 260,000 tests in all of 1965, the new technology soon empowered it to perform 8- 10,000 tests per day [5]. The important result, of course, was not that the cost per test fell; rather it was the fact that tests could be ordered when considered clinically important. Thus, an effectiveness measure of TEDIUM based only on the cost per delivered line of code might obscure its more significant contributions.

The theme of this paper is that there are high risks in developing systems with open requirements; the resulting product may not be useful. The fragment-based specification of TEDIUM is intended to reduce that risk by supporting the development of large, complex, and valid systems; by effectively responding to the evolving requirements; and by sustaining high developer productivity. That is, productivity alone is not sufficient. A new development paradigm for systems with open requirements must also demonstrate its ability to achieve validity and maintainability. Although there are some objective measures for productivity, evaluations of validity and maintainability are subjective.

This evaluation of the cost effectiveness of TEDIUM is derived from project experience with the largest system developed with this environment: the Johns Hopkins Oncology Clinical Information System (OCIS) [31]. OCIS evolved in response to the open requirement, “Improve the delivery of care for cancer patients through the use of automation.” It now operates on a network of 5 computers accessing a distributed database. There are more than 200 terminals on the system, and it is used by 100 staff members each day in support of their clinical mission. OCIS provides online access to some half- million patient days of care, it assists in functions unique to this category of patient, and it offers specialized administrative features. Considered one of the most comprehensive clinical information systems available for tertiary care, versions of OCIS have been installed in Australia and Ohio. Its users like the system, and because they rely on it in making life- threatening decisionsthey consider it robust and error free. Thus, OCIS is accepted as a valid response to the Oncology Center’s evolving needs.

Work on OCIS began in 1976; the development of the TEDIUM version was started in 1980 and completed in 1983. During the first years following its installation, there were computer operating system problems that inhibited respon- siveness. These were resolved in 1986, and, according to an analysis conducted in 1992 [18], the system since has grown by 10% in each of the last five years. This growth, illustrated in Table I, indicates how OCIS has evolved as

~- ~- I


TABLE I system by the cumulative number of effort days expended). . . GROWTH OF OCIS The net productivity in 1984 is close to a program a day; as

Date Programs Tables Elements Effort PED programs are retired and more effort is expended in maintain- Aug 1983 3662 848 2025 19 0.86 ing older programs, the net cumulative effort falls to .7 PED.

This productivity is made possible by the compactness of the TEDIUM program specifications, which average 15 “lines.”

Dec 1989 7695 1920 3281 48 0.71 Studies have shown that the length of the specification and

0.93

o,73

Dec 1984 5024 1045 2298 24 Sep 1986 5541 1375 2613 33 0.75 Jun 1988 6605 1635 2924 40

Feb 1992 9257 2273 3823 59 0.70

its requirements were refined and extended. It shows the number of program, table, and element fragments in the ADB specification at various points in the system’s life. (The effort and P E D columns are described below.) This growth in size is a reflection of OCIS’s growth in functionality. Changes to the system typically take one of two forms. In some cases, a need is identified but there is uncertainty about the best response to that need. Although a prototype sometimes is helpful, in most instances a production-quality set of tools, which relies on a real database used in an operational setting, is necessary to develop a sound understanding of an effective automated solution. In this case, once the needs are understood, the old system is retired, and a new system is installed. In most situations, however, OCIS growth results from the addition of new functionality [32, 331. There is a dynamic in which experience with OCIS improves the domain understanding of both the users and designers. As a consequence, new functions can be identified by the users or suggested by the designers, thereby accelerating the identification of useful and valid extensions. The availability of the enlarged computing resources, together with the existence of a sizable and accurate database, furthers this growth by enabling functions that otherwise might not be considered feasible. With a responsive environment, the boundary for change enlarges until it is constrained only by the ability to define and absorb new features [15].

It is difficult to compare relative development costs between OCIS using TEDIUM or some other language. For example, the size of the OCIS fragment-based specification is some 100,000 “lines.” To provide the equivalent functionality in a COBOL application would require a two-miIlion-line system [4]. But such an alternative is not reasonable. There is evidence to suggest that the cost per line of code is relatively independent of the target language [22], [61], and that individual productivity is inversely proportional to project size [41] (a fact explained by the communications overhead in any large project [22]). Therefore, a choice between TEDIUM and COBOL would have been a choice between a 6-person project that could adapt to the users’ changing needs and a 100- person project that must be carefully managed and structured. Obviously, not only could the Oncology Center not afford such a large-scale project, but a project of that size also could not respond to the Center’s evolving understanding.

Given that comparative productivity measures are not feasible, there are some helpful characterizing measures. The final two columns in Table I display the total cumulative effort (in effort years) expended on OCIS and the net number of production programs produced per effort day (PED, computed by dividing the number of programs in the current production

the functionality provided by the specification are independent of each other [7]. For example, Albrecht and Gaffney have demonstrated that the number of lines of code necessary per function point varies with the language used [l]. Therefore, the more compact the specification for expressing a concept, the higher the productivity. Thus, whereas productivity on the order of a 300-line program per day is difficult to sustain, the creation of a 15-line program a day is an achievable target.

In conclusion, there are three dimensions to an economic justification of TEDIUM: productivity, validity, and maintainability. With respect to productivity, there are several ways of viewing OCIS. It provides the functionality of a two- million-line COBOL application, its implementation exists as a one-million-line MUMPS application, and its fragment- based specification is compact enough to be maintained by a staff of 6. With respect to most measures of productivity (e.g., the number of delivered lines of code per effort month), the performance of the TEDIUM designers is unexceptional; with respect to the alternative representations for the identical functionality, however, the representation scheme of TEDIUM is extraordinary. Thus, TEDIUM’S productivity leverage is a function of its representation scheme. It is compact and expresses the important concepts; in Simon’s words, it confronts the design problem by “representing it so as to make the solution transparent.” The second criteria, validity, is demonstrated by the users’ acceptance of OCIS; it is relied on in making life-threatening decisions, its users accept it as error free, and the system is viewed as a viable avenue for confronting most clinical information needs. (A more complete evaluation of the system’s validity is in [31].) Finally, maintainability @e., the ability to evolve in response to changing requirements) is confirmed by the growth data in Table I. It shows that during the last five years analyzed, a fixed staff maintained a growing number of programs while also adding new functionality at an average rate of 20 programs per week. That is, the output of new programs remained constant even though the number of programs to be maintained increased. Thus, validity was preserved as productivity improved and maintenance became easier [MI. It follows, then, that even though the benefit derived from the use of TEDIUM cannot be expressed as a numerical value, a strong economic justification for TEDIUM exists.

B. Frugment-Bused Specif cutions

Although there are no standard evaluation criteria for a specification, several guidelines, introduced in the 1970s, identify some important criteria for the effectiveness of any representation scheme. Pamas stated that the specification scheme must provide to both the intended user and the implementer all the information needed by each, but nothing more (Le., information hiding). He also asserted that the

BLUM REPRESENTING OPEN REQUIREMENTS WITH A FRAGMENT-BASED SPECIFICATION 73 3

specification must be formal so that it can conceivably be machine tested, and it must “discuss the program in the terms used by user and implementer alike (i.e., not some abstract formalism)” [50, p. 3301. Liskov and Zilles extended the criteria as follows [45].

Formality: It should be written in a notation that is mathematically sound. This is a mandatory criterion.

Constructibility: One should be able to construct specifications without undo difficulty.

Comprehensibility: A trained person should be able to reconstruct the concept by reading the specificationhfinimality: The specification should contain the interesting properties of the concept and nothing more.

wide Range of Applicability: The technique should be able to describe a large number of concept classes easily.

Extensibility: A small change in the concept should produce only a small change to the specification.

Both sets of specification criteria were demonstrated with a concrete concept (Le., the stack), and this section extends these concepts to large-scale systems. The question is twofold: Do the criteria scale up for the specification of a large system (e.g., one whose implementation constitutes a million lines of code), and, if yes, does the fragment-based specification of TEDIUM satisfy the criteria? The evaluation assumes that the criteria do scale up and considers only the second issue.

There is no need to prove that TEDIUM’S fragment-based specification is mathematically sound; the fact that it is used to generate complete and correct implementations demonstrates that it is sound. Therefore, only the remaining five properties are considered. The discussion begins with the properties of applicability and minimality, and it then uses OCIS project data to characterize constructibility, comprehensibility, and extensibility.

wide Range of Applicability: One desirable property of a representation scheme is that it apply to a wide range of concepts. TEDIUM has been optimized for interactive information systems, but there is nothing in its architecture that restricts it to this class of application. The basic design recognizes that requirements engineering is domain oriented, and no one environment (or specification language) will suffice for all domains. TEDIUM uses application-class knowledge to tailor the system to a particular class of needs, and the architecture permits the introduction of system styles for new domains (e.g., real-time and embedded systems).

Even though TEDIUM may be employed with multiple application classes, it has only been demonstrated in the domain of interactive information systems. This domain, however, is itself quite broad; it includes clinical information systems, many software tools, and some AI applications. TEDIUM has been implemented in TEDIUM, and the multi-language version of the TEDIUM program generator is a TEDIUM application. In the domain of AI applications, TEDIUM has been used to implement an Intelligent Navigational Assis- tant that interprets user queries expressed without relation bindings [9], [19]. Although OCIS has been presented as a single system, it is really an integrated collection of support services that includes almost every category of task within the framework of information systems. Its functions range from

the mundane (e.g., the scheduling of outpatient appointments) to the specialized (e.g., protocol-directed management of patients, a function similar to that provided by the ONCOCIN expert system [40]). Clearly, the range of applicability for TEDIUM’S fragment-based specifications is far broader than that demonstrated with 4GLs and most research specification schemes.

Minimality: Liskov and Zilles defined minimality in the sense that Parnas defined information hiding. The specification should provide only the necessary information and nothing more. In the 1970s, the concepts of interest were modules (actually, data abstractions, which in an object-based environment become modules). In the TEDIUM environment the concepts to be specified are computer-supported responses to a need. Nevertheless, the goal remains the same: to have the implementer specify the interesting properties of the concept and nothing more. TEDIUM addresses this challenge by providing 1) a holistic ADB in which all concepts are shared within an application, 2) a specification command language that reduces housekeeping concerns, and 3) a system style that augments the specification of the interesting properties with the implicit and default properties expected in the implementation. Within the ADB the interesting properties are specified in the form of a schema and program specifications, and the TEDIUM representation scheme employs the most-compact representation. The productivity reported in the previous section is a consequence of the fragment-based specification’s minimality.

Constructibility: Constructibility is the ability to construct specifications without undo difficulty. The fact that productivity in OCIS over a 13-year period is 0.7 production programs per effort day is a clear demonstration that the fragment-based specifications facilitate construction. (Productivity rates of two or more programs per effort day are common for smaller projects [9].) Several studies have shown that individual differences are within a factor of two with respect to two measures of performance (number of programs developed and number of edits required) [8], [9]. In general, knowledge of the application is a better predictor of performance than training in computer science; half of the current Oncology Center staff began their careers as computer operators. Thus, it is not difficult to teach designers to use TEDIUM effectively.

In addition to this general evidence of productivity, constructibility can be demonstrated by the ease with which designers create and maintain program specifications. One measure of the ability of a designer to express his compu- tational intent is the number of times a program is edited. If this number is low, then it can be concluded that the designer has had little difficulty in expressing his intent. (A high number, on the other hand, can have many causes such as improper training, poor problem understanding, or a clumsy development environment.) In studies conducted from 1984 through 1989 the median number of edits was 10; in 1992 it grew to 11. The count includes all changes to a specification for debugging and maintenance-corrective, adaptive, and perfective-throughout the program’s active lifetime. Such a total number of edits over a 12-year period clearly suggests that the representation scheme offers an effective description of the interesting properties of the item specified.

~


Comprehensibility: Comprehensibility requires that a trained person be able to reconstruct the concept by reading the specification. In TEDIUM, the conceptual model in the ADB is viewed as a statement of the problem and its solution; it should be “close77 to the designers’ mental models. Thus, comprehensibility can be demonstrated if it can be shown that a designer who understands the problems being addressed (i.e., the Oncology Center’s needs) and the specification language (Le., TEDIUM’S ADB interface) has little difficulty in creating and revising the specifications.

A measure of comprehensibility can be found in the relative ease that designers have in modifying programs that they did not create initially. Three groups of people were responsible for developing OCIS. One group, composed of seven software professionals, supported the initial development and left the project after OCIS became operational in 1983. A second group consisted of four Oncology Center employees who par- ticipated in the initial development and assumed responsibility for the system’s evolution. A third group of four developers was hired in 1990 and 1991. Because most of the original system designers were not available, the staff had to modify many specifications they did not define. This need to modify the specifications of others was especially critical in 1991, when half the development team was new to the project. Nevertheless, the availability of a complete conceptual model in the ADB facilitated continued high productivity. An analysis of the change data shows that:

70% of all program specifications were edited at least one year after their initial design. Of these edits, 44% were made by persons other than the original designer. 26% of all table specifications were edited at least one year after their initial design. Of these edits, 38% were made by persons other than the original designer.

Therefore, the data show that TEDIUM requirements specifications are comprehensible.

Extensibility: The final criterion concerns the ability of the environment to have small changes in the requirements produce only a small change to the specification. With TEDIUM, the specification is maintained holistically, and it models a response to a set of needs in the application domain. Because those needs are deeply integrated, the specification in the ADB should reflect that degree of integration. Therefore, to demonstrate extensibility, the degree of integration within the ADB is examined. Small changes external to OCIS should lead to small changes to OCIS, and the new and changed fragments should be integrated with the unchanged fragments. Thus, design integration may be taken as an indicator of extensibility.

During the period being studied, the size of the OCIS specification almost tripled. If its conceptual model adapted to this need to evolve, then one would expect to find that changes ripple throughout the ADB. Although some of these effects will be transparent to the designers, many application extensions will require changes to other portions of the application to take advantage of the new features (e.g., the addition of a new function implies a need to change a menu). The following illustrates the degree to which the ADB design is integrated.

In the 13-month period from January 1991 to February 1992, 1049 programs were added to OCIS and another 3045 programs were edited. That is, 44% of the 9257- program system was affected during that time. This work was accomplished by a staff averaging 6 FTEs, and the system was considered to be error free throughout this period.

Another analysis showed that half the programs in- voked by programs in the original 1983 system were defined in 1984 or later. For the programs defined before 1987, more than 10% of the programs they invoke were defined at least two years after the invoking program was defined.

Approximately 20% of the tables read by the programs in the 1992 production system were not defined until at least a year after the program reading it was designed. These data demonstrate that the specification of OCIS is

highly dynamic and deeply integrated, which illustrates the extensibility of the TEDIUM representation scheme. The data also offer a valuable insight into a system with open requirements. Its architecture is holistic, a characteristic that echoes the form of the system’s conceptual model. Most elements are connected to each other, and those connections adapt as new requirements are introduced and satisfied. The existing system is viewed as a resource for its extension, and design decisions are made at a global level. In contrast, in a highly structured, hierarchical architecture, the objective is to limit changes to single (or at best a small number of) leaf nodes. Some modem modularization techniques (e.g., object-oriented [ 161) are more flexible in providing for communication among leaf nodes, and the fragment-based representation is the most accommodating scheme. In the past, we have constrained our solution space by the architectures we could support. As a result, dynamic integration of the degree found in OCIS was excluded as “bad design.” But, as the OCIS experience demonstrates, this is the form of the problem space, and we now must turn to the development of architectures that will support the requisite solutions.

V. CONCLUSION

Engineering disciplines are founded on the basic principle of deciding what is to be done before doing it. Previous experience is used to guide new developments. When the prior experience is deficient, it is augmented through ex- perimentation, prototyping, analysis, simulation, etc. One of the earliest goals of software engineering was to bring software projects into conformity with this principle, and today’s achievements suggest that this was the correct decision. But the accomplishments of computer technology now challenge this approach. One the one hand, the software systems being developed are becoming increasingly difficult to understand in advance, and on the other hand, the technology itself enables the implementation of alternative development paradigms.

This paper began with a systems analysis of the software process. It asked if the traditional two-step approach to development was necessary, and-if not-what alternative forms of requirement were possible. The conclusion was that for open requirements in a flexible project setting, there


are considerable advantages to an as-built specification: it evolves with growing understanding, it retains its validity, it is always up to date, and it is change oriented. Because the as-built specification is, in reality, a conceptual model of the target system, it is important that its representation scheme capture the specification’s conceptual essence. Nontraditional forms, which draw on the special capabilities of software, are necessary to support this form of conceptual modeling.

The organization of the as-built specification presented in this paper is fragment-based; it captures what is known about the application under development in a holistic structure. The obvious advantages of this scheme are that it is compact, integrated, and nonredundant. The disadvantage is that the specification cannot exist outside its environment. The viability of the approach was demonstrated with an environment that has been in production use for more than a decade. It was shown that the specification’s compactness, flexibility, and unity improve productivity, validity, and maintainability-essential criteria for applications with open requirements. It further was shown that most of the benefits of the development environment can be traced back to the properties of the representation scheme. A second evaluation illustrated that the representation scheme also exhibits the properties that software engineers consider important.

Unfortunately, the adoption of a fragment-based specification requires a paradigm shift in that this new form of specification represents “a reconstruction of the field from new fundamentals, a reconstruction that changes some of the field’s [i.e., software engineering’s] most elementary generalizations as well as many of its paradigm methods and applications” [42, pp. 851. Therefore, one cannot expect an evolutionary transition to fragment-based specifications; a discrete change is necessary. Yet, when one considers the revolution that computing has brought about in the past few decades, such a call for change surely is not unreasonable.

In summary, this paper has questioned how we develop software and offered experience with an alternative approach. I believe that most of the problems we will confront in the next millennium will have open requirements, and our methods must be able to accommodate this inherent uncertainty. Fortunately, there are some unique properties of software that permit the use of techniques that significantly differ from our current methods (e.g., the fragment-based, as- built specification). This paper has demonstrated that, for the class of interactive information systems, viable alternatives are within the state of the art. Moreover, by building new system styles, the technique demonstrated by TEDIUM can be extended to other, more complex, application classes and domains. Clearly, the path is strewn with difficulties, and generalizations from the TEDIUM experience may not bring success. Nevertheless, the potential for gain is so great, we would be foolish not to explore this new direction.

REFERENCES

[l] A. J. Albrecht and J. E. Gaffney, “Software function, source lines of code, and development effort prediction: A software science validation,” IEEE Trans. Software Eng., vol. SE-9, pp. 639-648, 1983.

[2] R. Baker, “A 15 year perspective on automatic programming,” IEEE Trans. Sofhyare Eng., vol. SE-11, pp. 1257-1268, 1985.

L. A. Belady, “From software engineering to knowledge engineering: The shape of the software industry in the 1990’s,” Int. J. Software Engineering and Knowledge Engineering, (l,l), pp.l-8, 1991. B. I. Blum, “MUMPS, TEDIUM, and productivity,” Proc. MEDCOMP, 1982, pp. 200-209. - , Clinical Information Systems. New York: Springer-Verlag, 1986. -, “Evaluating alternative paradigms: A case study,” Large Scale Syst., vol. 12, pp.18!%199, 1987. -, “Volume, distance and productivity”, J. Syst. Software, vol. 10,

-, “Improving software maintenance by learning from the past: a case study,” Proc. IEEE, 77, pp. 506-606, 1989. TEDIUM and the Software Process. Cambridge, MA: MIT Press, 1990. -, “Towards a uniform structured representation for application generation,” Int. J. Software Eng. Knowledge Eng., vol. 1, pp. 39-55. 1991. -, “A ten-year evaluation of an atypical software environment,” Software En. J., vof. 6 , pp. 347-354, 1991. -, Software Engineering: A Holistic View. New York Oxford Univ. Press, 1992. - , “On the Development of Hardware and Software,” Information and Decision Technology, vol. 18, pp. 375-394, 1992. -, “TEDIUM’S window into design,” in Proc. Con5 on software Engineering and Knowledge Engineering, pp. 202-205, 1992. -, “The dynamics of a clinical information system,” MEDINFO

-, “A taxonomy of software development methods,” APL Research Center Rep. RMI-91423, revised Jan. 1993. -, “The fourth decade of software engineering: Some issues in knowledge management,” Inter. J. Intelligent and Cooperative Inform. Syst., vol. 1, pp. 475-514, 1992. __, “Resolving the software paradox,” J. Software Maintenance, (in press). B. I. Blum, S. D. Diamond, M. G. Hammond, M. E. Perkins, and R. D. Semmel, “An intelligent navigational assistant for a decision resource database,” in Proc. Expert Syst. Gov., 1987, pp. 19-25. B.W. Boehm, “A spiral model of software development and enhance- ment,” Computer, vol. 21, no. 5, pp. 61-72, 1988. ___, “DARPA software strategic plan,” Proc. ISTO Software Tech- nology Community Meeting, June 27-29, 1990. F. P. Brooks, Jr., The Mythical Man-Month,. Reading, MA: Addison- Wesley, 1975. F. P. Brooks, Jr., “No silver bullet,” Computer, vol. 20, no. 4, pp. 10-19, 1987. J. R. Cameron, “An overview of JSD, ”IEEE Trans. Software Eng., vol. SE-12, pp. 222-240, 1986. P. S. Chen, Database Design Based on Entity and Relationship, in S. B. Yao, Ed., Principles of Database Design, Englewood Cliffs, NJ: Prentice-Hall, 1985, pp. 174-210. B. Curtis, H. Krasner and N. Iscoe, “A field study of the software design process for large systems,” Comm. ACM, vol. 31, pp. 1268-1287, 1988. A. M. Davis, “A taxonomy for the early stages of the software development cycle,” J. Syst. Softw., vol. 8, no 4, 1988. A. M. Davis, Software Requirements Analysis and Specification Engle- wood Cliffs, NJ: Prentice Hall, 1990. T. DeMarco, Controlling Software Projects. New York Yourdon, 1982. M. Dorfman and R. H. Thayer, Standards, Guidelines, and Examples on System and Software Requirements Engineering. Washington, DC: IEEE Computer SOC. Press, 1990. J. P. Enterline, R. E. Lenhard and B. I. Blum, Eds., A Clinical Information System for Oncology. New York Springer-Verlag, 1989. 3. P. Enterline, F. M. Majidi, L. L. Ogorzalek, et al., “Integrated ambulatory care services in oncology,” in Proc. 16th Annu. SCAMC, pp. 197-201, 1992. .I. P. Enterline, F. M. Majidi, C. M. Rossiter, et al., “The oncology clinical information system,” Proc. 16th Annu. SCAMC, 1992, pp.

A. Finkelstein, Ed., Proc., First Int. Conf Requirements Eng., 1993. T. Gilb, Principles of Software Engineering Management. Reading, M A Addison Wesley, 1988. H. Gomaa and D. B. H. Scott, “Prototyping as a tool in the specification of user requirements,” in Proc. Int. Conf S.E., pp. 333-342, 1981. R. Guindon,” Designing the design process: Exploiting opportunistic thoughts,” Human-Computer Interaction, vol. 5 , pp. 305-344, 1990. D. H a d , “Biting the silver bullet,” Computer, pp. 8-20, January, 1992. D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-Trauring, and M. Trakhtenrot, “STATEMATE: A working

pp. 217-226, 1989.

92, pp. 168-173, 1992.

835-836.


environment for the development of complex reactive systems,” IEEE Trans. Software Eng., vol. SE-16, pp. 403-414, 1990.

[40] D. H. Hickman, E. H. Shortliffe, M. B. Bischoff, A. C. Scott, and C. D. Jacobs,“ A study of the treatment advice of a computer-based chemotherapy protocol advisor,” Ann. Intern. Med., vol. 101, pp. 928, 1985.

[41] T. C. Jones, “The limits of programmer productivity,” Guide and Share Application Development Symp..

[42] T. S . Kuhn, The Structure of Scientific Revolutions, second ed.. Chicago: Univ. Chicago Press, 1970.

[43] M. M. Lehman, “Life cycles and laws of program evolution,” Proc. IEEE, 68, pp. 106CL1076, 1980.

[44] M. M. Lehman, V. Stenning and W. M. Turski, “Another look at software design methodology,” ACMSIGSOFT SEN, vol. 9, no. 3, 1984.

[45] B. H. Liskov and S. N. Zilles, “Specification techniques for data abstraction,” IEEE Trans. Software Eng., vol. SE-1, pp. 7-19, 1975.

[46] M. R. Lowry, “Software engineering in the Twenty-First Century,” AI Magazine, pp. 71-87, Fall 1992.

[47] H. D. Mills, R. C. Linger, M. Dyer and R. E. Quinnan, “The management of software engineering,”IBMSyst. J., vol. 24, no. 2, pp. 41477, 1980.

[48] J. Musa, Ed., “Stimulating software engineering progress, a report of the software engineering planning group,” ACM SIGSOFT SEN, vol. 8, no. 2, pp. 29-54, 1983.

1491 J. M. Neighbors, “DRACO: A method for engineering reusable software systems,” in T. J. Biggerstaff and A. J. Perli , Eds., Software Reusability. New York: ACM Press, 1989, vol. 1, pp. 295-319.

[50] D. L. Parnas, “A technique for software module specification with examples,” Comm. ACM, 15, pp. 33CL336, 1972.

[51] K. R. Popper, TheLogic OfScientific Discovery. New York: Harper & Row, 1959.

[52] R. Prieto-Diaz and G. Arango, Tutorial: Domain Analysis and Software Systems Modeling. Washington, DC: IEEE Computer Society Press, 1991.

[53] W. W. Royce, Managing the “Development of large software systems,”

[54] W. Royce, “TRW’s Ada process model for incremental development of large software systems,” in Proc. Int. Conf: Software Eng., 1990.

1551 A. P. Sage, Systems Engineering. [56] M. Shaw, “Prospects for an engineering discipline of software,” Soft-

ware, pp. 15-24, Nov. 1990. [57] H. A. Simon, The Sciences of the Artificial. Cambridge, M A MIT

Press, 1969.

New York: Share, 1979.

IEEE WESCON, pp. 1-9, 1970.

New York: Wiley, 1992.

[58] G. F. Smith, “Towards a heuristic theory of problem structuring,” Management Sci., 34, pp. 1489-1506, 1988.

[59] R. H. Thayer and M. Dorfman, Systems and Software Requirements Engineering.

[60] I. Vessey and D. Galletta, “Cognitive fit: An empirical study of information acquisition,” Inform. Syst. Res., vol. 2, pp. 63-84, 1991.

[61] A. I. Wasserman, P. A. Pircher, D. T. Shewmake and M. L. Kersten, “Developing interactive information systems with the user software eneineerine. methodology.” IEEE Trans. Sofhvare Enn., vol. SE- 12, pp.

Washington, D C IEEE Computer SOC. Press, 1990.

_. 32C345, i986.

1621 G. Wiederhold. P. Wegner, and S. Ceri, “A paradigm for component- .~ based programming,” Eomm. ACM, vol. 35, pp. 89199, 1992. .

[63] R. T. Yeh, “System development as a wicked problem,” Int. J . Software Eng. Knowl. Eng., 1, pp. 117-130, 1991.

[64] P. Zave, “The operational versus the conventional approach to software development,” Comm. ACM, vol. 27, pp. 104-118, 1984.

[65] P. Zave and W. Schell, Salient “Features of an executable language and its environment,” IEEE Trans. Software Eng., vol. SE-12, pp. 312-325, 1986.

Bruce I. Blum received the masters degree in history from Columbia University and the masters degree in mathematics from the University of Mary- land.

He has been active in the field of computing since 1962.i~ a member of the Principal Professional Staff of the Johns Hopkins University Applied Physics Laboratory and an Associate Professor of biomedi- cal engineering in the School of Medicine. He also teaches software engineering in the Department of Computer Science in the Whiting School of Engi-

neering. He has served as a project manager for a major NASA contract, was a vice president of Wolf Research and Development, and has been responsible for the design and implementation of information systems for NASA, the Navy, the Johns Hopkins Medical Institutions, and other organizations. Since 1981 he has been conducting research in software engineering.

Date post:	20-Sep-2016
Category:	Documents
Upload:	bi
View:	213 times
Download:	0 times

Representing open requirements with a fragment-based specification

Documents