Achieving requirements reuse: A domain-specific approach from avionics

Achieving Requirements Reuse: A Domain-Specific Approach from Avionics

W. Lam Rolls-Royce UniversityTechnology Centre, The Universityof York, Heslington, York YOl 5DD, UnitedKingdom

The reuse of requirements has received little attention in the literature, especially in relation to genuine industrial experience. This paper describes the efforts being made to promote the reuse of requirements for engine control systems at Rolls-Smith Engine Controls Limited (RoSEC). Our approach is based on existing domain analysis techniques, and we relate our experience of applying these techniques to develop a core set of generic requirements. A forms-based tool that we have prototyped which supports the reuse of requirements during the development of new systems is also presented, and is compared with existing reuse tools. The paper concludes with a discussion on the possible impact of this work on RoSEC’s current requirements engineering process. 0 1997 Elsevier Science Inc.

1. INTRODUCTION For three years now, the Rolls-Royce University Technology Centre (UK) at the University of York has been promoting reuse within and across the families of civil engine control system software produced by Rolls-Smith Engine Controls Limited (RoSEC). However, we have noticed that while code reuse is regularly addressed in the literature (Booth, 1987; Solder&h, 1989; Davis, 19951, the reuse of requirements has received relatively little attention, especially in relation to genuine ‘industrial experience, To address this imbalance, this article de-

Address correspondence to K Lam, Department of Computer Science, University of Hertfordshire College Lane, Hatfield Herts, AL10 9AB, United Kingdom. J. SYSTEMS SOFTWARE 1997; 38:197-209 0 1997 Elsevier Science Inc. AU rights reserved. 655 Avenue of the Americas, New York, NY 10010

scribes the current efforts that are being made to achieve requirements reuse at RoSEC. It has been argued that reuse at the requirements level can significantly increase reuse at later stages of development (Biggerstaff and Ritcher, 1987; SPC, 1992). Many of the existing ideas being adopted by the reuse research community are based on the idea of program ‘families’ first described by Parnas (1976). In recent years, the original systems families concept has been extended by work in domain analysis, which Prieto-Diaz (1990) defines as “a process by which information used in developing software systems b identified, captured, and organised with the purpose of making it reusable when creatingnew vstems”. One of the first studies of domain analysis methods argued that the early domain analysis methods were more geared towards code reuse, rather than design or requirements reuse (Wartik and Prieto-Diaz, 1992). Since then, more recent approaches have emerged, claiming a more holistic view of reuse throughout the development life cycle (Tracz et al., 1993; Gommaa, 1995; STARS, 1995; Tracz 1995). The work in this article describes our experience of requirements reuse on an industrial case-study within RoSEC. The format is as follows. Section 2 gives a brief introduction to the avionics domain we studied and presents the motivations for reuse. In Section 3, we outline RoSEC’s existing requirements engineering process, highlighting the diverse nature of the requirements involved. Section 4 provides an overview of the approach we used to achieve systematic requirements reuse. Section 5 then summarizes the domain analysis we performed to identify and package reusable requirements in the domain, pointing out the key observations that were made. Section

0164-1212/97/$17.00 PI1 SO164-1212(96)00151-3

198

W. Lam

J. SYSTEMS SOFTWARE 1997; 38~197-209

6 describes the prototype tool we have developed to enable requirements to be reused during the development of new systems. In Section 7, we evaluate the tool and draw attention to related work. Finally, Section 8 concludes with a discussion on how this work is likely to affect requirements engineering practices at RoSEC in the future and highlights where further work is being directed.

Table 1. The reuse scope table

FAl FA2 FA3

FA4 FA5 2. THE DOMAIN: ENGINE

FULL AUTHORITY CONTROLLERS

DIGITAL

RoSEC produces control software for Full Authority Digital Engine Controllers (FADECS). In essence, the FADEC provides a computer controlled management system for the engine. The FADEC takes inputs from the cockpit and sensors located on the aircraft, and produces outputs (in the form of electronic signals) for controlling the engine (Figure 1). An engine series (family) is composed of marks and variants. A mark is a specific engine within a series. A variant is a mark that is produced to the specific requirements of an airframer (such as Boeing or Airbus). The reuse scope table in Table 1 illustrates the potential for reuse. The left column represents the functional areas (FA) of the FADEC (such as heat management, engine starting, and thrust reversal). The top row represents an engine series in terms of marks and variants. The intersections indicate requirements: common requirements for a functional area (CR); requirements specific to a functional area and an engine mark (Mkl, Mk2, etc.); and requirements specific to a functional area, an engine mark and a variant (MklVarl, MklVad, Mk2Var1, etc.).

.-. _-+_---._

._-_ _ ..-

---- --

Pilot-to-Controller Input

.-..-.-

Mark 1 Variant 1

Mark 1 Variant 2

Mark 2 Variant 1

Other Projects

CR, Mkl, MklVarl CR, Mkl, MklVarl CR, Mkl, MklVarl

CR, Mkl, MklVar2 CR, Mkl, MklVar2 CR, Mkl, MklVar2

CR, Mk2, MMVarl CR, Mk2, Mk2Varl CR, Mk2,

CR, MkY MkYVarZ CR, MkY MkYVarZ CR, MkY

CR, Mkl, MklVarl CR, Mkl,

CR, Mkl, MklVar2 CR, Mkl,

Mk2Varl CR, Mk2, Mk2Varl CR, Mk2,

MkYVarZ CR, MkY MkYVarZ

MklVarl

MklVar2

Mk2Varl

CR, MkY MkYVarZ

The reuse table highlights two levels of reuse possible for FADEC requirements: common requirements for a functional area and common requirements for a functional area specific to an engine mark but not a variant. 3. THE EXISTING ENGINEERING

REQUIREMENTS PROCESS

RoSEC’s current requirements engineering process for FADECs is based around a number of key documents, as shown in Figure 2. In brief, the ah-framer (the client in this case) supplies the System Requirements Document (SRD), which describes in broad terms the functionality required of the FADEC, and the System Concept Document @CD) which lays down constraints relating to the design of the aircraft itself. From this, the different functional areas of the required FADEC are examined in greater detail by engineers at

___&_-_---_

Pilot-to_Cmtroller output I

I

Figure 1. Schematic view of a FADEC.

Figure 2. Documents

neering process.

in the current

requirements engi-

Achieving Requirements

J. SYSTEMS SOFTWARE

Reuse

RoSEC, leading the production of a Functional Requirement Document (FRD) for each functional area. The FRD relates to system requirements, which is followed by the production of the Software Requirements Document (SWRD). Because of the similarity often found between FADEC systems at the SRD level, engineers are often tempted to reuse requirements by ‘cutting and pasting’ at the FRD and SWRD level. Although this appears a natural strategy for producing new (but similar) documents, it is inefficient for a number of reasons: Engineers often spend a significant amount of time reworking the copied requirements into the desired form. The reworking process is not repeatable, nor does it have any general structure which could be easily reapplied. No savings are gained later during design, implementation, or testing since the reworked requirements are, for all intent and purposes, treated as ‘new’ requirements. In short, the problem is that requirements are being reused, but in an ad hoc, nonsystematic and localized manner which does not leverage the full benefits of reuse.

5. DOMAIN

ANALYSIS

We used an existing domain analysis method, ODM (STARS, 1995), to guide our own domain analysis of FADEC engine starting requirements as much as possible. We chose ODM because of its wide publication, copious documentation (Version 1.0 of the guidebook is 338 pages long) and history of usage. However, because our focus was on reusing requirements (as opposed to designs or code), we tailored our treatment of ODM accordingly. In short though, we performed the same cycle of understandidentify-abstract activities characterized in a typical domain analysis: Understand the domain by reading background material, existing system documentation, and by speaking to domain experts. Identify frequently reoccurring requirements in the domain and use abstraction to develop truly generic and reusable requirements. Rather than overload the reader with all the fine details of our domain analysis, we instead state the key ideas, principles, or lessons from each main stage, illustrated with extracts where appropriate.

5.1 Understand

4. DOMAIN-SPECIFIC APPROACH

REQUIREMENTS

199

1997:38~197-209

REUSE:

OVERVIEW

Much of the current interest within the reuse research community is directed towards domainspecific reuse (see (WISR, 1995) for example), where a domain is characterized by a family of systems (Gomaa, 1995). Given that we could envisage a family of FADECs, we felt it appropriate to use a domain-specific approach for requirements reuse in our case study. However, given the broad nature of the FADEC domain, we decided to focus on a subdomain of FADEC requirements-engine starting (arguably a domain in its own right). In a nutshell, engine starting refers to the rotation of the engine from a still position to a speed sufficient for ignition and the sustaining of that speed until the engine is idle. Like most domain-specific approaches, we had two main phases to the case study: a domain analysis phase to identify reusable artifacts in the domain, and a domain engineering phase to package the reusable artifacts in such a way that facilitated reuse during the development of new applications. We describe these two phases in the next two sections.

the Engine Starting Domain

Being new to engine starting, we spent some time coming to terms with the concepts in the domain. The key ideas, principles, and lessons during this stage are given below. An Evolving Domain Definition. Ways of defining and scoping a domain is the source of much debate within the reuse community (see (Svoboda et al. (1996), for example). In practice, we found it difficult to ‘pin down’ or define the exact boundaries of the starting domain right at the beginning of our domain analysis. The starting domain, for example, includes elements from overlapping domains such as engine ignition, engine relighting and engine shutdown, which only became apparent to us when the domain analysis was well underway. Early Abstraction from Examples and Identification of Key Issues. We read the available FRDs for four different starting systems. This provided a lot of detailed system-specific information, but at the same time, we were able to see the issues, or requirements focal areas, which were common to all starting systems (Table 2).

200

W. Lam

J. SYSTEMS SOFIWARE 1997; 38~197-209

Table 2. Issues in the starting domain

5.2 Identify and Abstract Reusable Requirements

Issues

Reuse implies that there is something already there to be reused. The next phase was to recognize and capture reusable requirements knowledge in the starting domain. The key ideas, principles, and lessons during this phase are given below.

ignition layout continuous ignition ignition fault accommodation engine relight

engine shutdown

cranking

rotor-bow protection

Description Depending upon where the aircraft is, its altitude, speed, and the receipt of the appropriate cockpit signals, an engine can be started in one of many different starting ‘modes’. The layout of ignition systems often vary. Continuous ignition, if a feature of the starting system, enables an engine to be continuously lit for a period of time. Specific procedures are carried out in the event of an Signition failure. Engine relight prevents a ‘flame-out’ condition when the igniter flame is extinguished. Shutting down an engine requires that certain engine components become disabled. Cranking is an engine maintenance feature, and refers to the starting of an engine without engine ignition. Rotor-bow protection prevents excessive damage being done to the motor in the event of the rotor-blades becoming locked.

Such issues enabled us to structure and focus the domain analysis in such a way that the relevant parts of the domain were being addressed. Acquiring Requirements Rationale. We believe requirements rationale to be a critical, yet overlooked aspect of domain analysis which deserves greater attention than currently received. Often, we found the rationale for some of the requirements in a FRD absent or difficult to comprehend, which impeded the domain analysis. For example, why there is a limit imposed on the number of engine restarts when the aircraft is on the ground (for safety reasons in order to force aircraft maintenance to take place). In such cases, it was vital to elicit the rationale from experts ‘inside’ knowledge in order to be able to reason about requirements in the domain. Combining Knowledge into a Coherent Picture. Only by combining the detailed system knowledge in the FRDs, the issues that we had abstracted and requirements rationale, did we reach an argued and coherent ‘picture’ of how starting systems worked. However, this appears to be more reliant on the individual’s own faculties of comprehension, rather than on any domain analysis technique per se. We spent two man-weeks on this stage, although our understanding of the starting domain still continued after this period during the course of domain analysis.

Formulate Generic Requirements from Concrete Ones by Reasoned Abstraction. In order to develop a highly reusable set of core requirements for all starting systems, we identified equivalent or matching requirements in the FRDs we had read. However, as these requirements were in a concrete form, i.e., specific to a particular FADEC starting system, it was necessary to abstract out the system-specific details to formulate truly generic requirements. Table 3 shows an example of this. In practice, we found the most difficult (and time-consuming) aspects of the above process was the identification of equivalent requirements (particularly when they are disguised in a concrete form), and the separation of the constant part of a requirement from the variable part. Table 3. Example of the abstraction process used to formulate a generic requirement Element in Abstraction Process concrete requirement from system A

equivalent concrete requirement from system B

constant requirement part

variable requirement part abstraction reasoning

generic requirement

Example When the engine is not in the process of being started, cranked or run, if the fuel switch is in the OFF position and the master crank switch is in the ON position, and the engine start switch is then turned to the ON position then a dry crank will be initiated. When the engine is not in the process of being started, cranked or run, if the fuel switch is in the OFF position and then the engine start switch is turned to the CRANK position, then a dry crank will be initiated. When the engine is not in the process of being started, cranked or run, if (Xl and then (Y), a dry crank will be initiated. X and Y are cockpit-specific signals. Cockpits are specific to a particular system, and not all systems will have the same cockpit layout. Hence, this aspect is a variable requirement part and must be factored out of the generic requirement. When the engine is not in the process of being started, cranked or run, if (cockpit signal 1) and then (cockpit signal 21, a dry crank will be initiated.

Achieving Requirements

Reuse

Factor-Out and Factor-In Lists. As we gained greater experience in analyzing concrete requirements, it became clear the kinds of information which were (and were not) being abstracted in the formulation of generic requirements. We felt this to be of important value, particularly for future domain analysis exercises, so we recorded our findings in factor-out and factor-in lists. Put simply, a factor-out list lists the types of knowledge to factor out of a concrete requirement in formulating a generic requirement, and vice-versa for a factor-in list. Table 4 shows, in concise form, a factor-out list which we have developed for requirements in the starting domain. Requirements Choice Sets. We found that some requirements had a defined range of options, which we chose to record as choice sets. For example, a FADEC system might have a requirement for ‘engine relight’ which automatically energizes the igniter when a flameout occurs (such as in the event of severe water ingestion). And associated with this

cockpit controls

sensor-specifics

EEC lanes

airframe-specifics

hard-codedvalues

requirement

201

is a number of choices:

The igniters are energized for a minimum specified period of time. The igniters are energized for a maximum specified period of time. The igniters are energized for a minimum and maximum specified period of time. The igniters are energized until manually switched off by the pilot. [n this case, the choice emerges from a balance of safety and maintenance issues (igniters have a limited life), but the key point here is that we have captured the typical forms in which the requirement is commonly used.

Advice

Anticipate Change and its Impact on Requirements. On some occasions it was not enough to simply base the abstractions on the information in the available FRDs. Some foresight and anticipation of change, both on a technological and commercial level, was needed to ensure that our generic requirements were going to be valid for all typical starting systems, now and in the future. The key to this was to leave the generic requirements as ‘open’ as possible, and to avoid making explicit assumptions about the technology.

Different aircraft will have a different cockpit layout. Instead, think in terms of a set of abstract signals such as engine start, engine stop, power on and power off which can be mapped onto a specific arrangement of cockpit controls. Different aircraft may use different sensors to achieve the same objective. For example, the sensors used for detecting that an aircraft is on the ground can vary from altimeter, weight on front wheels, weight on back wheels or any combination of sensors. Reference to specitic sensors should therefore be replaced with what the sensor’s objective is (such as to detect if the aircraft is on the ground). The EEC (Electronic Engine Controller) usually has a dual-lane architecture. However, hardware advancements or alternative designs may result in more sophisticated architectures being used. Therefore, the assumption that the EEC will always have a dual-lane architecture should not be made. Airframes are rarely the same. Variance can occur in terms of power supply, aircraft electrics and hardware devices, just to mention a few. These specifics need to be generalized. Reference to specific values should be avoided. Instead, use a ‘variable’ instead, for example, ‘Fuel-on-Speed’, as opposed to a real number.

Don’t Overabstract, Use Sense and Judgement to Identify Meaningful Abstractions. Although abstraction is central to developing reusable requirements, it must be applied sensibly with judgment about how meaningful the resulting abstraction will be. For example, we found it pointless to try and abstract requirements for ignition fault handling because there was so little in the way of common structures. Another example where judgment was needed was in the abstraction of requirements for ‘start modes’. In brief, an engine is started in different modes, depending upon where the aircraft is (on the ground or in-flight) and how fast it is traveling. Figure 3 shows two different abstraction strategies which could be applied. In the first (top) strategy, three generic set of requirements are advocated, based on three different types of start mode. A specific ground start can be derived from the generic ground start. In the second strategy, a single generic set of requirements is advocated for all start modes, from which all specific starts are derived. While the second strategy captures the similarity between all start modes, and appears more appealing, it suffers from greater complexity due to the increased parameterization. Our point is that the abstraction process can be more

Table 4. A factor-out list for starting Information to Factor-Out

J. SYSTEMS SOFTWARE 1997: 38:197-209

202

w.Lam

J. SYSTEMS SOFTWARE 1997; 38:197-209

Table 5. Some measuresfrom our domain analysis Characteristic

Value

Number of different starting FRDs analyzed’ Average length of an FRD

4

Average number of requirements per FRD Number of requirements considered common or highly reusable Total time spent on domain analysis Time spent information gathering Time spent on creating a core set of generic requirements Number of domain analysts Number of domain experts (or experienced individuals) involved Number of interviews with domain experts Length of each interview (doesn’t include occasional telephone conversation) Number of generic requirements created so far

Figure 3. Two abstraction strategies.

involved than it first appears, requiring some thought about the implications of alternative abstraction strategies. Output from Domain Analysis. In sum, we acquired the following information from our domain analysis: A list of issues which structured the starting domain in terms of requirements focal points. A set of generic requirements (grouped according to which issue it pertains), which can be reused in the requirements engineering process for new starting systems. Choice sets for particular generic requirements representing standard configurations of the requirement. Factor-in and factor-out lists which describes abstraction information-useful for future domain analysis work in the starting domain. Personal gains in knowledge about how starting systems work and how their requirements are specified at RoSEC. Summary of Domain Analysis Exercise. Table 5 provides some measures which indicate the scale of the starting domain and our domain analysis case study (sadly missing from much of the published domain analysis work).

35 single-side A4 sheets (single-line spacing) 125 36 (29% of a typical FRD) 5 man-weeks 2 man-weeks 3 man-weeks 1 3 4 1 hour

28

‘Although four different starting FRDs were analyzed, only three were taken into account when calculating the other measures, as one was a demonstrator system and not truly representative of a customer-delivered system.

RoSEC associates a unique identifier with every statement in the FRD considered a requirement, which provided a primitive but convenient basis for providing rough reuse measures. Surprisingly, we found that only about 29% of a FRD is considered reusable-we expected a higher percentage. This may be due the fact that the ‘high-level’ requirements between starting systems are similar, giving an overall impression of similarity or an identity of a family. However, most of the requirements in an FRD are low-level requirements and are more detailed in nature, thus reducing their capacity to be reused or made reusable. It should be noted that a significant amount of our time on the domain analysis was spent learning ‘how to do’ a domain analysis on requirements (as we had never done one before). Next time, we hope our experience here will enable us to concentrate more on the domain analysis per se. As yet, we have not reached the point where we have enough cost and timescale data to evaluate the impact of reuse on a real project. Such information will only be available when reuse has been properly integrated into RoSEC’s existing requirements engineering process. 6. DOMAIN

ENGINEERING: THE DEVELOPMENT OF THE COMPASS

As indicated

TOOL

earlier, the motivations for reuse at RoSEC include desired reductions in cost and time-

Achieving Requirements

Reuse

scales for FADEC development. For the case study here, we wanted to demonstrate to RoSEC engineers and managers how we could streamline the development of FRDs which was central to their existing requirements engineering process. Central to this was to show how the reusable requirements, developed from our domain analysis, could be deployed as the basis for a proposed rapid FRD construction process. We felt that a tool, as opposed to simply a proposed methods document, which engineers and managers could themselves experiment with, would provide a tangible and effective vehicle for demonstrating the potential benefits. Architecture of COMPASS. So far, we have spent two man-months on the development of the COMPASS (COMPonent Assistant) tool, the architecture of which is shown in Figure 4 (although the early version of the prototype reported here makes some implementation concessions). COMPASS is a MS Visual Basic application running under Windows 3.1. COMPASS uses a formsbased interface to enable the user, a RoSEC engineer, to ‘fill in’ generic requirements. The forms library stores the forms (which are internal to COMPASS), and a forms manager controls the interaction with the user. A rules library stores constraints (if any) about how a form can be filled in, and the forms checker applies these rules, usually dynamically, when the user completes a form. Generic requirements from the domain analysis are stored in the reuse library (an MS Access database). The purpose of the requirements builder is to retrieve generic requirements from the reuse library, instantiate them with the information provided in the forms, and place the resulting require-

J. SYSTEMS SOFTWARE 1997: 38:197-209

203

ments into the project library (another MS Access database). The FRD generator creates a text file from a simple dump of the project library. The capabilities of MS Visual Basic has enabled us to construct a working prototype of COMPASS within three man-weeks. We will now explain in more detail the specific features of COMPASS. Formation of Reusable Requirement Components. A popular notion of reuse is that of reusable components, which can be parametized for a specific application and combined with other components (hinted at in the original component factory paradigm of McIlroy (1969)). We applied the same principle to requirements to create the notion of a reusable requirements component (RRC). We define an RRC as an encapsulation of closely related generic requirements. To illustrate, Table 6 shows the four generic requirements that comprise the engine-relight RRC. Our motivation for this is derived from the observation that certain requirements in the starting domain will always appear together. An RRC is a reflection of this in an explicit form, and may be reused in a self-contained manner by simply providing the parameters to the generic requirements contained within. At present, we have defined 13 RRC for the starting domain, having from one to five generic requirements. Figure 5 shows, from a user’s point of view, the list of RRCs currently available starting in COMPASS. Forms-Based Requirements Collection. In COMPASS, each RRC is provided with an ‘interface’ called a form. A form provides an engineer with a means of reusing, in a controlled manner, an RRC during the development of a new FRD. To illustrate, Figure 6 shows the form for the engine-relight RRC which was described in Table 6 earlier. The form provides a number of ‘fields’ for an engineer to fill in. The fields correspond to the

Table 6. Generic requirements which comprise the engine relight RRC Generic Requirement

Figure 4.

Architecture of the COMPASS tool.

When the engine relight is armed, a flameout is deemed to have occurred when (flameout criteria) is true. When the engine is running, engine relight shall be armed when (cockpit signals) is received. When the engine is armed, it shall be disarmed when (cockpit signals) is received. When a flameout is detected, the EEC shall command (which igniter) to ON for a period of time equal to (delay period).

204

W. Lam

J. SYSTEMS SOFI’WARE 1997; 38:197-209

Figure 5. The RRC component list in COMPASS.

parameters of the generic requirements encapsulated by the RRC, so that filling in a form is equivalent to making the generic requirements concrete, as illustrated in Table 7. For the benefit of the user, every form has a preset component description field, which briefly summarizes the RRC. Figure 7 shows a less complex form, pertaining to the wet crank RRC. A wet crank refers to the situation when the engine is rotated, with the fuel on but not ignited (typically used during engine maintenance). Here, the user needs to fill in the fields ‘start’ and ‘stop’ with the particular cockpit-specific sequence which starts and stops the wet crank. In this case, the start field has been filled in by the engineer.

Error-Checking Rules and Guidelines. The design of each form, such as the use of option buttons and checkboxes, to a large extent minimizes erroneous reuse of an RRC. However, a few simple error-checking rules are a feature of COMPASS which ensure that the RRC is reused in a controlled manner. For example, typing anything other than a number in a numeric field produces an error message. These local error-checking rules, however, are distinguished from COMPASS guidelines, which provide method guidance. For example, attempting

Figure 6. The form for the engine relight RRC.

Table 7. Link between the fields and the parameters of a generic requirement Form Field

Field T)pe

Generic Requirement

Flameout detection: there are two ways to detect a flameout: by a drop in engine shaft acceleration or by a drop in engine shaft speed. Both methods may be used. Amx what the pilot does to turn on engine relight.

Checkbox

When the engine relight is armed, a flameout is deemed to have occurred when (flameout criteria) is true.

Text

Disarm: what the pilot does to turn off the engine relight.

Text

the igniter Igniters: which is operated under engine relight; this is either the left or right igniter, or both.

Option

When the engine is running, engine relight shall be armed when (cockpit signals) is received. When the engine is armed, it shall be disarmed when (cockpit signals) is received. When a flameout is detected, the EEC shall command (which igniter) to ON for a period of time equal to (delay period).

Delay period: the length of time the igniter(s) remain on for after being turned on.

Numeric

Achieving Requirements

Reuse

J. SYSTEMS SOFTWARE 1997:38~197-209

205

ments into the project database; and then generate a FRD from a simple dump of the project database into a text file.

7. EVALUATION COMPARISON

OF COMPASS AND TO RELATED WORK

Related Work

Figure 7. The form for the wet crank RRC.

to select the dry to wet crank RRC before the wet crank RRC produces the guidance message shown in Figure 8. This is because it makes sense to complete the wet crank RRC first and reflects the procedure that an expert or experienced engineer in the starting domain would normally follow. A suggested order for completing RRCs is built into COMPASS, enabling COMPASS to suggest to the user which RRC should be completed next on the basis of which RRCs have been completed already.

From the literature, there appears to be a growing interest in tool support for reuse, motivated in part by the maturity of reuse practice in a number of organizations. In order to first differentiate the different types of reuse tools, we propose the following classification in Table 8 (note that a useful classification of reuse technologies can be found in (Biggerstaff and Richter, 1987) and (Mili et al., 1995)). The classification is not a ‘pure’ classification, as a degree of overlap between classifications exists; for example, a domain-specific kit is likely to include a library for storing reusable artifacts. It is interesting to note that application generators match reusable designs and code against a given specification, and so reuse begins at the design level rather than at the requirements level as envisaged here. We see COMPASS coming closest to being a domain-specific kit, primarily because of its broad aim to provide a stand-alone means of requirements reuse within a chosen domain.

Evaluating

FRD Generation. As mentioned earlier, central to RoSEC’s existing requirements engineering process is the production of FRDs, which acts as a contractual document between RoSEC and the client. COMPASS is able to process the information provided by an engineer through its forms; retrieve the relevant generic requirements pertaining to the RRC from the reuse library; instantiate them using the information given; place the instantiated require-

Select Wet Crank Component First.

as a Domain-Specific

Kit

Griss and Wentzel (1995) provide a framework for evaluating domain-specific kits based on kit elements and pre-defined attributes of each kit elements. Although their framework is geared towards code-based kits, as opposed to requirements-based kits, we nevertheless felt that using their framework to evaluate COMPASS would help identify possible areas of improvement. A brief description of the most pertinent kit elements and kit element attributes (relating to this work) are shown in Tables 9 and 10, respectively (taken from (Griss and Wentzel, 1995)). Our analysis of COMPASS using the Griss and Wentzel framework is summarized in Table 11. The analysis has forced us to think more deeply about COMPASS; in particular, the following weaknesses have been highlighted: l

Figure 8. A guidance message.

COMPASS

COMPASS is extensible in terms of adding new components, but this is a function which is restricted to the COMPASS tool developer. There are no maintenance features directly available to

206

W. Lam

J. SYSTEMS SOFI-WARE 1997; 38~197-209

Table 8. A classification scheme for reuse tools class of Reuse Tool

library

retrieval

domain-specific kit

application generator

project management

Table 9. Description of Klt Elements

Description

Kit Element

Description

A library stores reusable artifacts, but performs no analysis over the reusable artifacts. A library might be seen as a source of corporate knowledge, and is often a central reuse tool. Frakes and Pole (1994) describe the effectiveness of reuse libraries based on an empirical study. A retrieval tool locates relevant reusable artifacts from a library. This is important when the library is large and unstructured. Retrieval techniques exist based on key-word search (Frakes and Nejmeh, 19881, faceted classification schemes (Prieto-Diaz and Freeman, 1987) and the formal quantification of similarity (Gstertag et al., 1992). Henninger (1994) has investigate automated support for retrieval in the CodeFinder tool. From their work at Hewlett-Packard Laboratories, Griss and Wentzel (1995) have proposed the notion of domain-specific kits as “a set of compatible, msable workprvducts that are architected to fit well together and are designed to make it easy to build a set of related application”. Application generators translate specifications into application programs and enable a general software design to be easily customixd. However, application generators are difficult to build, requiring knowledge of parsers and language translators in addition to domain knowledge (Cleaveland, 1988). Transformation systems, such as Neighbor’s (1989) early work on Draco, might also be seen as application generators. These tools are used to plan, resource, and monitor reuse projects. They may also provide ,budgeting f~ctions.

components

Software components and component documentation. ‘Ihe application framework instantiates the common portion of the application architecture, provides common mechanisms, services, and components that shape all applications built from the kit. A kit usuahy includes some way of connecting components to each other and to the framework. A tool that generates kit components, glue, contigurations, parameters, or some other application-specific element from application specitications. A tool, often graphical, that allows a kit user to develop applications by selecting and composing components, by filling in templates, or by editing specifications. Documentation on using the kit to develop applications. Graphical or textual model of the application domain, usually a result of domain analysis. A kit may include several generic (prebuilt) applications as examples developed from the kit, or as the bases that application developers can modify and extend to develop applications.

framework

glue language

generator

builder

kit use documentation domain model

generic applications

Evaluating

COMPASS:

the Engineer’s View

As well as using Griss and Wentzel’s

evaluation framework, we released a fhst version of the prototype for engineers at RoSEC to experiment with and provided a number of demonstrations to managers. One of the weaknesses with using Griss and Wentzel’s evaluation framework was that it shed light on the COMPASS tool, but not on the reuse concepts underlying the tool. However, engineers and managers appeared more interested in the underlying reuse concepts, and from their feedback, the following comments can be made: l

The RRCS are too simplistic, and need to be made more jhible. This points to our domain analysis: did we identify all the generic requirements? did

the user, which would appear essential in light of the evolutionary nature of domain-specific reuse. COMPASS might benefit from a stronger notion of a glue language: our use of rules for describing how different components relate to each other may suffice for now but may prove difficult to manage with a large number of components. There is a direct link between a form, the RRC, and the underlying generic requirements. However, this link is not currently enforced, relying on the tool developer to ensure that the relationship is fully maintained.

Table 10. Description of Kit Element Attributes Attribute

Description

pr;ren;

Is this element a part of this kit? Is its absence noteworthy? How complete is this element of the kit? Does it cover everything needed from it for develop ment of the target applications? HOW easiIy can elements or new features be added to the kit or to the developed applications? How specific to the target application domain is this element of the kit?

in

completeness

openness

domain Specificity

Achieving Requirements

Reuse

J. SYSI’EMS SOFlWARE

207

1997: 38:197-209

Table 11. Evaluation of COMPASS using the G&s and Wentzel framework Element components

framework

glue language

generator builder

kit use dots domain model

generic

Presence as

“Forms” RFCs

representing

organization of the domain in terms of our choice of RRCs. no explicit glue language, but rules which govern component ordering and component checking simple FRJ_I report generator a graphical interface for forms-filling based on Windows user guide, developer directly contactable the generic requirements in the reux library

Domain StXcificitY

Completeness

Openness

not complete with respect to the starting domain but provides a common, reusable core

new forms can be. added by

complete with respect to the present collection of components

new rules can be added by the tool developer

rules will be spcific to starting systems omy

generic requirements can be added to the reuse library

generic requirements specific to starting omy

user guide gives only a basic introduction not complete, reuse library still evolving

the tool developer, together with an ass&ated set of generic requirements added to the reuse library

specific to starting systems only

no sample applications applications included

we make them sufficiently abstract? can the generic requirements be made more flexible via further parametization ? We are currently conducting a more in-depth study in order to answer these questions. Novel nzquirements are not catered for. Our pro-

posed requirements engineering process is based upon the reuse of typical, rather than novel requirements which, by their very nature, are reuseresistant. Simply tagging on novel requirements appears the simplest way to deal with this problem, but we are concerned that this might disrupt the resulting specification, for example, by introducing an inconsistency with a requirement already derived from a generic requirement. The automatically generated FRD is too simphtic. At present, a FRD is generated by dumping the contents of the project database into a text file. We are in the process of adding a numbering scheme, a predefined document structure and annotated text to the FRD. We are also looking at possible methods of integrating FRD generation with the word-processing package MS-Word to make the documents more visually appealing; this is particularly important when the document is to be used as a formal report by different people. No prototyping capability Our notion of reuse is largely oriented towards the rapid production of

documents. We have yet to investigate how the reuse of requirements might lead to the rapid production of a prototype. Overall, we can deal with the first three areas of concern in the short term, and include the improvements in a second release of COMPASS. Thus, we remain positive about the direction we are taking. The prototyping capability issue is a more complex area, but we feel that it can be tackled by developing a generic prototype, reflecting the generic requirements, and with tailorable elements which map onto the parameters of the generic requirements. This is one area currently under investigation.

8. CONCLUSIONS

AND

FURTHER WORK

This paper has reported on the use of domain analysis techniques to encourage the reuse of requirements for FADEC systems at RoSEC. Although requirements reuse has been studied from a number of interesting angles-analogical reasoning (Finkelstein, 1988; Maiden and Sutcliffe, 19921, case-based reasoning (Lam, 1994), difference-based reasoning (Miriyala and Harandi, 1991) and domain modeling (Bolton et al., 1994; Ryan and Mathews, 1993)-these ideas are restricted to small, academic examples which are distanced from the industrial

208

W. Lam

J. SYSTEMS SOFTWARE 1997; 38:197-209

domains of importance to RoSEC. Instead, we chose to use a domain-specific approach, which exploits reuse by recognizing a family of FADECs. We feel that we have made a number of contributions in this paper. First, there have been (as far as the author is aware) no other reported industrial applications of domain analysis methods concentrating specifically on requirements. Here we have shown how the notion of issues can be used to structure a domain and the domain analysis process. In addition, we have demonstrated how reusable, generic requirements can be formulated by an abstraction process from concrete requirements, and how knowledge about the abstraction process can be documented in factor-out and factor-in lists which can also be used to guide future domain analyses. The need for requirements rationale as an integral element of domain analysis was also highlighted, despite being somewhat overlooked in the existing domain analysis literature. Perhaps most importantly, we have raised questions about the effectiveness of existing domain analysis methods; it is true they provide a framework for domain analysis, but this is far removed from the detailed method guidance necessary to actually perform a successful domain analysis. Our second area of contribution is in reuse tools. To make reuse effective, we need to bridge the gap between the products of a domain analysis (in this case, reusable requirements), and the exploitation of those products in the development of new systems. In COMPASS, we have demonstrated a novel way of bridging this gap in a relatively simple and unsophisticated manner (when compared, for example, to application generations or transformation systems) so that the benefits of reuse are immediate rather than delayed. Although the forms-based style of COMPASS lacks an underlying, single language for describing component connection or consistency, we believe that its conceptual simplicity aids its general acceptance by engineers at RoSEC. There are a number of limitations to this work which will be the focus of further work. First, we have described some of the reuse processes (such as rationale acquisition and abstraction) used to produce reusable, generic requirements. However, our work was performed in the context of requirements expressed as natural English statements, rather than in a graphical or formal notation. While we do feel that the same reuse processes apply, our instincts tell us the abstraction process at a detailed level will be different (with state-transition diagrams for example, we would be thinking in terms of abstract states and system-specific states). In this respect,

work by Castano et al. (1994) comparing the reusability of different (graphical) specification notations does provide some insight into this area. Second, we recognize that a single case study is limited in terms of what it can tell us about domain analysis. One hypothesis is that domain analysis is different when applied to different stages of the software engineering process. For example, a domain analysis of requirements will require different tactics from a domain analysis of designs. Should such a hypothesis be supported, existing domain analysis methods which endorse a uniform and monolithic process over all stages of the software engineering process need to be re-examined. However, we need further comparative case-studies to investigate this further, and it is the focus of ongoing research at the UTC. While the lessons here, as in any case study, are context dependent, they are of general value to other organizations embarking on reuse projects, particularly where the focus of reuse is on requirements. With the notion of reusable requirement components (RRC), a step closer has been made towards a COTS (Commercial Off the-Shelf) vision of system development at RoSEC. Perhaps more importantly, we have raised the thought process within RoSEC from one where systems were developed ‘from scratch’ to one where systems are built from predefined components. This is a cultural barrier that we are now slowly beginning to erode. The COMPASS tool has provided RoSEC (and ourselves at the UTC) with a taste of what a rapid FRD production process, based on reuse, might look like. Although we cannot claim that the reuse work here has had a direct impact on RoSEC’s existing business-critical requirements engineering process, we can claim to have influenced process changes in the future. Already, RoSEC has benefited from previous reuse work by the UTC and has begun its development of a central reuse library fashioned along World Wide Web technology. The work on requirements reuse here has prompted questions about how such a reuse library will support reusable requirements and has highlighted the considerations for an in-house domain analysis method. As a final lesson, our experience leads us to believe that existing reuse technology cannot be used ‘as is’, but must be carefully planned and adapted to fit into an organization.

ACKNOWLEDGMENTS The author Roils-Royce

acknowledges the financial support given by Plc. for the work reported in this article. The

Achieving

Requirements

Reuse

J. SYSTEMS SOFTWARE 1997: 38~197-209

assistance of the staff at the UTC and RoSEC is also greatly appreciated.

Formal Software Specifications From Informal Descriptions. IEEE Transactions on Sofhyare Engineering, 17(10):1126-1142

Biggerstaff, T., and Richter, C., Reusability Framework, Assessment and Directions. IEEE Software, 41(3) (March, 1987). Bolton, D., Jones, S., Till, D., Furber, D., and Green, S., Using domain knowledge in requirements capture and formal specification construction. In: (M. Jirotka, and J. Goguen, Eds.), Requirements Engineering: Social and Technical Issues, Academic Press, London, 1994. Booth, G., Software Components with Ada, Benjamin/ Cummings, Menlo Park, CA, 1987. Castano, S., De Antonellis, V., Francalanci, C. and Pernici, B., A Reusability-Based Comparison of Requirement Specification Methodologies. In: Methods and Associated Tools for the Information Systems Life Cycle, (A. A. Verrijn-Stuart and T. W. Olle, Eds.) Elsevier Science B.V. (North-Holland), 1994. Cleaveland, J. G., Building Application Generators. ZEEE Software, 25-33 (July, 1988). Davis, M. J., Adaptable, reusable code. In: Proceedings of the ACM SIGSOFT

Symposium on Software Reusability,

Seattle, Washington, April 28-30, 1995. Finkelstein, A., Reuse of Formatted Requirements Specifications. Software Engineering Journal, 3(5):186-197 (1988).

Frakes, W. B., and Nejmeh, B. A., Representing Reusable Software. Information and Software Technology, 32(10):653-664

(1988).

Frakes, W. B., and Pole, T., An Empirical Study of Representation Methods for Reusable Software. IEEE Transactions on Software Engineering, (August, 1994). Gomaa, H., Reusable Software Requirements and Architectures for Families of Systems. Journal of Systems and Software, 28:189-202

(1995).

Griss, M. L., and Wentzel, K. D., Hybrid Domain-Specific Kits. Journal Systems and Software, 30:213-230 (1995). Henninger, S., Information Access Tools for Software Reuse. Journal Systems and Software, 30:231-247 (1995). Henninger, S., Using Iterative Refinement to Find Reusable Software. IEEE Software 11(5):48-59 (1994). Lam, W., Reasoning About Requirements From Past Cases, Ph.D. Thesis, Kings College, University of London, 1994. Maiden, N., and Sutcliffe, A., Exploiting Reusable Specification Through Analogy. Communications of the ACM, 35(4):55-64

(1991).

McIlroy, M. D., Mass-produced

REFERENCES

(1993).

Mili, H., Mili, F., and Mili, A., Reusing Software: Issues and Research Directions. IEEE Transactions on Software Engineering, 21(6):528-561

(1995).

Miriyala, K., and Harandi, T. H., Automatic Derivation of

209

Software Components,

Software Engineering Concepts and Techniques, 1968 NATO Conference on Software Engineering, pp. 88-98,

eds. J. M. Buxton, P. Naur and B. Randell, Petrocelli/Charter, New York, 1969. Neighbors, J., Draco: a method for engineering reusable software systems. In: Software Reusability, (T. Biggerstaff and A. Perlis, eds.), Vol. 1. Addison-Wesley 1989, pp. 295-319. Ostertag, E., Hendler, J., Prieto-Diaz, R., and Braun, C., Computing Similarity in a Reuse Library System: An AI-based Approach. ACM Transactions on Sof?ware Engineering and Methodology, 1(3):205-228

(1992).

Parnas, D. L., On the Design and Development of Program Families. IEEE Transactions on Sofkvare Engineering, Vol SE-2, (March, 1976). Prieto-Diaz, R., Domain Analysis: An Introduction. ACM SZGSOFT (1990).

Software

Engineering

Notes,

15(2):47-54

Prieto-Diaz, R., and Freeman, P., Classifying Software for Reusability. IEEE Software, (January, 1987). Ryan, K., and Mathews, B., Matching conceptual graphs as an aid to requirements reuse. In: Proceedings of the IEEE International Symposium on Requirements Engineering, ISBN o-8186-3120-1, pp. 112-120, 1993.

Solderitsch, J. J., Wallnau, K. C., and Thalhamer, J. A., Constructing Domain-Specific Ada Reuse Libraries. In: Proceedings of the Seventh Annual Conference on Ada Technology, Ft. Monmouth, N. J., March, 1989.

SPC, Software Productivity Consortium Reuse Adoption Guidebook Version 01.00.03, SPC-92051-CMC, November, 1992. STARS, Organisation Domain Modeling Guidebook STARS-VC-AO23/011/00, March, 1995. Svoboda, F., Maymir-Ducharme, F., and Poulin, J., Domain Analysis in the DOD. So&are Engineering Notes, 21(1):55-67 (January 1996). Tracz, W., DSSA (Domain-Specific Software Architecture) Pedagogical Example. ACM SIGSOFT Software Engineering Notes, 20(3):49-62

(1995).

Tracz, W., Coglianese, L., and Young, P., A DomainSpecific Software Architecture Engineering Process Outline. ACM SZGSOFT Software Engineering Notes, 18(2):40-49

(1993).

Wartik, S., and Prieto-Diaz, P., Criteria for Comparing Reuse-Oriented Domain Analysis Approaches. Intemational Journal of Sof?ware Engineering and Knowledge Engineeting, 2(3):403-431 (1992).

WISR, Proceedings of the 7th Annual Workshop on Software Reuse August 28-30, St. Charles, Illinois, 1995.