an object-oriented tool for tracing requirements

0

FRANcrsco A.C. PINHEIR0 and JOSEPH A. GOGUEN, Oxford University

Layge-scale development demands tyacirag mpirements and other objects in the face o f continuous evolution. Reguiwzwnts change in natwe, scope, content, andf imz t o become mow consistent, accwa te, complete, and cleaic We pyesent a tyacing tool that suppom evolUtion

oftware practitioners generally agree that tracing requirements is essential in developing large systems. Tracing helps verify system features against the requirements specification, identify error sources, and - most importantly - manage change. In this article, we describe a tool called TOOR (Traceability of 0 b j e c t - 0 r i e n t e d Re quire m e n ts) . 0 f course , the

requirements themselves are not necessarily object-oriented. Our tool’s name is derived more from its use for object-oriented development and its object-oriented implementation, which allows the definition of classes and subclasses of objects and relationships among objects.

TOOR is based on Joseph Gogueii’s broad view of requirements,’ which suggests that not only technical but also social factors play a significant role in software development. These dual aspects have been called the d~ and the wet.* Here we talk about tracing requirements, but what we say applies equally well to any other artifacts produced in a software project; they too can be traced if they are registered in TOOR. The trace procedure we describe here is motivated by the following observations:

0 7 4 0 7459/96/505 00 D 1996 I E E E M A R C H 1996

+ Requirements evolve throughout the life of a system. T h e y change in nature, from general to specific, they change in scope, hy incorporating new features and deleting old ones, and they change in content a n d in form, t o ticcome more consistent, precise, and cle‘ir I’hey ,ire a l \ o relatcd to each other mtl to other drufacts invohed in system development. ivorcover, these connections ~ 1 s o evolve over time.

+ Recluirements ‘ire cztziated, in that they depend upon details of the p‘irticu- lar situation or context in which they arise. You i ~ i y need to reference those details to interpret thc requirements directly. Requirements are qotznted in that the) rcsult from discussions among

iiitercsted parties, the outcome of which depends on the parties’ interests, orga- nizational position, technical background, and othcr factors. Moreover, the relations of requirements to one another and to other objects also arise through ncgotiation and dcpend upon context. For example, t o say tha t a requirement is d w i z d from soine docu- inciit will have different meanings in different cotltexts. A trace procedure will be more useful if it can account for this sitiintedmss, letting users do what is most appropriate in each situation.

+ Tracing requirements is also situ- ated. This implies that a trace should produce objects that are rncaningful for that situation.

OTHER TOOLS AND APPROACHES For re~sons of space, this

sidebar only gives short cri- tiques of a few most closely related systems a i d ai)- proaches. ARTS’ 1s a well esta1)lished tool tor tracing requirements, supporting trxeability through a hicrar- chic‘il s t i~ictuic for linking rcquirenients It also supports search b‘ised on requirements ‘ittri butcs. Several s j steins are b‘ised on IBIS-likc motlels,’ aimed a t caphiring dcsign rationJc’ by recording discussions and decisions about require- incnts in n network of z \ m e c , ,m~ti071\, md ni;qiimei?tJ connected by special links. The Kcinap system4 rcpresents deieloping systems. this approach well. In this model, requirements c m generate issues and lcatl to decisions th,it affect design ohJccts, they Cdl l ‘1150 he motiified by decisions. The R E I X tool’ focuses on the early ph‘ises of softmare

development and supports requircmeiits trace‘ibility through hypertext, where nodes are frames holding requirements artifacts.

Othei works emphasix the xtivities performed in developing softmare. For cuample, the N‘iture project6 uses the notions of N C ~ Z U ~ , ut- zultioiz, i o n t e z t , and ~ C U ~ Z O I I to givc seniaiitic definitions for tools and en\iroixnents that produce software systems, based on torinally specified rclations that allow the tracing of objects other than requirements. The ~oiz t i -zba-

tzoii sti M

crs v m (

Requii ements artifacts are vieu ed as toiztizbutzont, and the agcnts involved in their produc tion as iontrzhutorc, thcse are related by to?ztrzhii- t/on I e h o n r . This approach suppoi ts pre-requireinents- specification traceability and

+ Requireiiieiits are a n inextrica- hle part of the development process, and tracing project artifacts forward and backward from requireirients is useful t h r o u g h o u t t h e life cycle. Registering requirements and r e la- tions among thein and other project artifacts is no t just a documentation chore, and tracing requirements (and other objects) is no t just a inanage- m e n t activity. Ins tead , impor t an t requirements issucs arise throughout the life cycle, and appropriate tool support can make i t much easier to resolve such issues. T h i s requires integrating requirenients with information about analysis, specification, coding, and so on.

i s implemented in a tool with a hypertext interkm for marked-up documents.

characterized as document based. One example is the Radix tool,‘ and another is the Sodos environment.” In Sodos, the outcomes of each software phase are registered as documents, and traceability is achieved by queries to a database. 01-lena Gotel provides a good survey of existing approaches.’

Some other work can be

REFERENCES

I E E E S O F T W A R E

Communications manager

Operations manager

intuitions and activities. T h e system consists of the following components, shown in Figure 1 :

+ An operations manager, which controls aiid executes all object and module operations, as well as the trace-

Figure 1. The TOOR ~~e.epuzireme?ztc-t~racz?lg system camstst\ of n datnbnse n~nnag-er, comvzumcatms manager, and ope~atzons nzanagei-, and zs layered atop the FOOPS obpt-oriented Language. ability mechanisms.

T w

4 A database manager, which controls access to the T O O R database and uses the FOOPS database to retrieve Dreviouslv defined FOOPS modules.

phases of system development. Its intu- itive, tenidate-based interhce is simDle

, I

In such a dynamic environment, enough so that nontechnical users can 4 A communicat ions manager , often involving many thousands of trace softu-are objects. In addition, which controls communication with rcquireinents, it is difficult for develop- requirements engineers, designers, and o ther systems, including F O O P S , ers to keep track of where they are in a programmers can use i t for creating, design tools, and WWW tools. It is also project, especially if they are new or maintaining, and browsing the database responsible for controlling user interac- working in a new area of the system. of objects and relations. Llore complex tion. Decisions about what should be modi- searches can use a small, regular-expres- In Figure 1, dashed lines indicate fied in view of a (potential) change may sion-based lanpage. FOOPS connections to other corupo- require knowing the evolution of the However, defining a project emiron- nents. FOOPS maintains and controls parts under consideration and tlieir con- ment requires more formal training. the T O O R database and is used to eval- ncctioiis. Moreover, the aspects to be T h e T O O R system adminis t ra tor uate most operations, objects, modules, retrieved are likely to vary depending should be trained in the use of formal and traces. on the context of the change and on the specifications, particularl!- FOOPS (for Throughout this article, we use a person assessing the change. Funct ional and Object-Oriented running exaniple to illustrate the most

Our traceability mechanism address- Programming S!rstem). ' n-hich is used es tliesc points, by providing to speci$ the TOOR project environ-

+ T h e use of relations instcad of ment. FOOPS is a general object-ori-

inelits to design documents, specifica- specification capabilities, providing tions, code, aiid otlier artifacts through objects, classes, inheritance, aiid other

important features of TOOR.

simple links. TOOR can link require- ented programming language with INlTl s T o use TOOR, the system admiiiis-

user-definable relations that are mean- object-oriented capabilities. FOOPS ingful for die kind of connection being was designed by Joseph Goguen and made. 'i'his lets developers distinguish Jose Meseguer' and iinpleniented by ainong different links between the same Goguen's student, iidolpho Soccoro.' objects. Also, by using mathematical FOOPS and TOOR are part of a wider properties of relations such as transitivi- approach t o system dere lopment , ty, T00R can relate objects that are including the unification of functional, not directly linked. This makes the trace object-oriented, and relational pro- procedure more powerful because it gramming paradigms,' and principles of allows identifying not only the objects architecture definition and system com- linked to a given object, but also the position.'-s T O O R ' s application to objects related to a given object by some requirements follows the hyperrequire- specific pattern of composed relations. ments approach described elsewhere."

+ T h e use of multiple, flexible ways T h e connection to FOOPS makes to trace requirements, iiicludiiig both ~ TOOR particularly suitable for an browsing and regular-expression search. ob j ec t- ori en te d s ys t ern- develop nien t

+ A facility for defining the systern- paradigm. TOOR uses FOOPS-like development environment, to support modules to declare requirements and to die niainteiiance of objects and relations automatically create new links as a pro- to be traced. ject evolves. It also provides hypermedia

We've designed TOOR for use in all facilities to more closely mirror analysts'

trator first creates a project specification that declares classes for requirements and any other objects you want to trace. T h e project specification, denoted PS, is F O O P S code. T O O R automatically creates a template for each class in the project specification, creating one field for each attribute of the associated class. When objects are added to the database, their attribute values are taken from the corresponding template fields.

A project specification is not a system specification, and it does not con- cern the classes involved in specifying a system. Instead, it declares the classes of artifacts that can be used, such as Document, V i deoS c ene, Requ i. r e - ment, Specification, and Test- Procedure. Thus, it is relatively sta- ble and can be used for a whole fanlily of projects. However, a project speci-

M A R C H 1996

fication can also be expected to evolve in tlie course of a project, because new classes of artifiicts may have to be rcgis- tered and existing classes niay have to be modified. Yet the classes of artifacts used in a project tend to stabilize over time, and overspecifying a project database is not as dangerous as overspecifjr- ing the system itself; users need not use all classes in the project specification, and thc adminis t ra tor can inhibi t unused classes f rom appearing i n TOOK menus.

Becausc the project specification is given in F O O P S , i t can easily he changed. Once the project specification is defined, tlie ordinary ‘100R user need only select the desired class and fill in the appropriate template to create, modifjr, or delete objects.

Creating obiects. ’I‘OOR is used in three phases. In the definitio7z phase, classes of objects to be traced and of connections among them are defined in the project specification. I n the regiytn- tion phase, objects and relations arc registered as the projcct evolves, using TOOR templates and multimedia fiacili- ties. Finally, in the extraction phase, traces are computed and presented using the modes described later.

W e intend for ‘1’OOR to he used during dcvelopment, ratlier than as an a posteniri documentation tool. Thus, its users include requirements engineers, d e signe rs , and pro gr a m me rs . 0 the r TOOR users rnay include adrninistra- tivc staff, such as managers, for whom its most likely use is trace extraction. Some T O O R data-input activities niay

igned to clerical staff. ven a project specification that

dcfines the classes and relations to be used in a project, users can start creating objects and relations.

The project specification for our exan- ple contains the module

omod STORED-DOC is class StoredDoc . extending DOCUMENT . protecting FILE .


/lidentification

/ I I

pzlm p q Figure 2. The document PS is regi.\te?-ed iiz TOOK u m ~ g this wzrzdow

subclass StoredDoc < Document at content : StoredDoc - >

FileName [redefl . endo

which dcfines a class StoredDoc for documents stored in the file system as a subclass of Document, which is imported from the module DOCUMENT. T h e STORED-DOC module takes a simple

attributes, desc and content, for description and content, respectively. T h e content attribute at is redefined [ red-ef ] to contain the name of the file where the document is kept. T h e sort F i . l e N a m e is defined in the imported module FILE. T h e keywords extending and protecting are used for these two module importations. T h e first indicates that something is being added to an old class, while the second indicates that nothing is being added. No methods are declared in STORED-DOC for changing attribute values because ‘IOOR autoniatically generates such niethods for each class.

Creating objects in TOOK involves selecting an appropriate class from a graphical menu and filling in the teinplate that pops up. Our running exan- ple involves a documcnt called PS (Problem Statement). Figure 2 shows

view of documents as havin, lr j USt two

T h e generic module below defines relations as used in the project specification; it has two formal arguments, x and Y. T h e module THOBJECT is a theory specifying syntactic and semantic CO ti-

straints on modules that can be arguments . T h e at t r ibutes Toor-re1 - source and Toor-rel-target are defined in terms of the formal arguments.

omod RELATION[X : : THOBJECT, Y : : THOBJECT] Its

class Relation . extending RELATION-IMAGES . subclass Relation < ToorRel . at Toor-rel-source : Relation - >

at Toor-rel-target : Relation - > 0bject.X [redefl .

0bject.Y [redefl . endo

T o declare a specific relation, tlie generic module is instantiated with actual modules and its class is renamed. For example, a relation between documents and requirements called Extl-act is defined by

omod EXTRACT is extending RELATION [DOCUMENT,

REQUIREMENT] * (class Relation to Fktract) .

at is-Extract : ToorObj

var R : IdList . ToorObj - > Boo1 .

how PS is re~iistered a$ an instance of vars 01 02 : ToorObj U

the class StoredDoc: After filling in rel-type(R) == Ordinary if R == all-Extract .

(irnage(all-Extract,Ol).OZ) . the template, clicking *e APP~Y button ax is-Extract(Ol ,02) = member invokes a FOOPS command that creates the obiect instance in the database. endo

OBJECTS 1

RELRTIOHS

TP001-trace-back]

source: ~~

TPOOl -Was: t-liac I:

target : P.D03-iJ.l#:t-ha,: 1,

71 d e l e t e ob.iect ~m

I R 1 1 Objects I

E4 E5 I:: TRMIl-sys T R 0 0 2 - s y s

TR004-rel TROVS-tp TRiWG-tp TRVO7-tp TRlNIS-tp TRlt51-tp TRlt52-tp TRll53-tp TRO61-tp TRll511-tp TR11512-tp TPIlIl1-trace-back Rllll3-trace-back

T R n n 3 -re 1

SPEC-trace-back

Passing the module DOCUMENT as an actual argument for x causes the class Object . X to he bound to Document. Similarly, O b j ec t . Y becoines bound to Requirement. T h e asterisk indicates a renaming, here renaming Relation to Extract. Therefore , Extract is defined as a relation from objects of class Document to objects of class Requirement.

Specifpig other classes and creating tlieir instances is similar. In particular, a relation is registered in TOOR using a template that has a sozirce field for its domain object and a t q e t field for its codomain (range) object. TOOR's object orientation provides great flexibility in the handling of objects and relations. For example, many subclasses of Requirement can be created for different types of functional and nonfunc- tional requirements. This information can be used in tracing requirements. For example, you can trace forward from requirements of class Per f o r - mance to see what effect changing diem might have.

TOOR objects can retain their original form. For example, if the minutes of

a meeting \\ere produced in TeX, the original 'rex bource file can he re@ tered in TOC>K; if the minutes were scribbled on the back of an envelope, then a scanned image of that envelope can be registered in TOOR. This great- ly enhances pre-requirements specification traceability, providing more accu- rate and reliable information about requirements production. It also facili- tates inserting 'TOOR into the derelop- ment process. For example, upon its completion a design chart can be registered in TOOK.

Understanding relations. Relations are the basis foi- traceability in T O O K . They differ from simple nanied links in that they are specified by axioms, thus giving much more flexibility. Axioms can be added or deleted f rom the FOOPS specifications to reflect particular situations. For example, a conditional axioni defining the relation Support based on Derive and Assert can be removed if i t is no longer considered valid. Also, new subclasses can be defined for relations.

Many natural links are autoniatically

created by subclass relations defined in the project specification. This inforina- tion can be used in tracing: You can trace requirements back to documents whose class is a subclass of Conf id- ential, for example. This, together with the fact that relations are user- definable, provides s a n e support for the situatedness of requireiiients because the objects used in a project and the possible relations among them are defined according to the particular context in which the project will be carried out . Moreover , dur ing t h e project changes can be made to reflect changes in the context.

Creating relations. A t m c e is a path or history, showing how some particular state came to be. Each step of such a history is an instance of some particular class of relation. For example, that the answers to a certain question on a certain questionnaire had a certain result. Such relationships can be of many different kinds and it would be difficult or impossible to determine all possible relations for all possible projects once and for all. For this reason, TOOR sup-

M A R C H 1 9 9 6

Extract- TROOl -sys Extract -4 TR002-sys Extract- TR003-re1 ,- Extract - * TR004-re1

Extract- TR005- tp

Extract --* TR007- tp Extract * TR008- tp

Extract- TROO6-tp

Figure 4. Relating iquwewents t o the document PS.

ports user-dehable relations and con- siders a trace to he a composition of such relations.

Assert ~ -El’ Extract-- * TROOl -sys Assert ~ - E 2 ~ Extract ---* TR002-sys Assert ~- - E 3 Extract - TR003-re \

.E4 -~ Extract ~- TR004-rel

Assert - E 7

PS

For each relation R i n the project SDecification. there is an attribute is-R

spondiiig identifiers. been replaced by more specific relations of statements to reouirements. Notice

which, wdien evaluated for an ohiect 01 Indirect relations. N o t all relations in that PS still relates directlv to reciuire- having object 02 as argument, produces the value true i f01 is related to 0 2 by K, and false otherwise. Depending on the type of the relation, which is given by the r el - type attribute, an appropriate set of axioms is chosen to compute the relation image. For example, Extract is defined to he of type ordinary, which means that 01 and 0 2 are related under R if and only if there is a link tietween 01 and 02. For a transi -~

tive type, 01 and 02 are related under R if there is a link between 01 and 02 or if there is an object 03 such that 01 is related to 03 and 0 3 is related to 0% under R. Of course, other mathematical relation types, such as ref] exive and symmetric, can also be defined. T h e

TOOK are direct links. In d ie case of a transitive relation, if A is linked to R and H is linked to C, there is no need to directly link A to C. T h e axioms for transitive relations give true as a result o f evaluating i . s - R e l J . t e d ( A , C) . Axioms can also be used to specifi. rclations that depend on the existence of

ment TR005-tp. The connection to the whole docuinent is not lost. W e assaci- ate zxtract to ParLOf because alf requirements extracted from a document d’ are also considered extracted from any document d wliich d’ is part of. This can he formally expressed as:

(tlr : Rcquiwment) (tl d, d ’ : Uo~-limei7?)(d:

EXt7-Lll.r.

We can implement this in FOOPS by placing thc following conditional axiom in the project specification:

otlier relations. 6-t A (d, d? € 1’N/.tOf’3 (d, 7i IE

Relating people to documents. Many different people may be inv-olved in producing a software ctocument, ancl they will have different views about what the requirements should be. A given docu- meiit only records the result of some if not empty(inter (image(all- particular set of negotiations at a par- PartOf.01) , counter-image(aI1- ticular time. In general, a document Extract,OZ) )

is.Extract(Ol ,02) = truf

axioms for computing the appropriate image are given in the module RCLR- TION-lMAGES, uhich IS imported into tlie Darnmetenzed module RELATION.

may contain statements that are not accepted by everyone in a group, those with other views just may not have been sufficientlv Dersuasive.

1 his says that 02 is extracted from o if therc is a coininon dement in the iin‘ige ot 01 under P a t o f and in the counter-

Figure 3 shows the screen for a relation between objects T P O 01 -trace- back and ROO?-trace-back. T h e steps taken to create this relation are as follows: First, click on the icon for Test relation in the menu. A window containing the teinplatc for this relation pops up, allowing object identifiers t u be typed into the source and target fields. Alternatively, another menu, shown in Figure 3, can he uscd to select

, I

One reason for rel‘iting documents to people IS to indicate who expressed or appi-oved thc content of the document. For example, particular st‘ite- inent5 in PS may be related to the people who stated tliein. For tliis purpose, we use tlie relatioii A\~e?t P e / ~ o i 7 x Stntewezt, where Staremezt Domment and statements are related to documents that contain diem by a relauon Pm-tOf’c l l o c m m ~ t x Doirimnpnt. This can provide

the desired objects The graphical con- vention for relation5 shows related ele- meiits linked by an arrow that has the name of thc relatlon in its middle. For example, each requirement in Figure 4 was related to PS by filling in the appropriate teinplate of Extract with corre-

a wny to check and discws requirements later on.

Fig-ure 5 reprcsents the new configuration of objects and relations if the people involved are Fred, Torn, a i d Jim. It also shows soine other changes The previous Extract relations have

irnagc of 02 under Extract. The finic- tions i.nter (for intcrsection of se.;s), image, and counter-image are all defined in the module K E T ~ A T I O N - IMAGES, which is iinportcd into the paranictcrized module K ETATI ON that TOOR uses to specifi. relations.

REQUIREMENTS EVOLUTION

In building a largc system, it may be nccess‘iry to negotiate conflicts, clarify the meaning of a term used in differimt contexts, and carefully ana1yL.c tradeoffs Moreover, new reldboiis among reqmre- ments, pcople, docurnents, concepts, and otlier objects may ‘ippe‘ir. Requirements


-~ Support

Tam - Assert - - t E l ~ Extract-- TROOl -sys Assert - E2 ~ Extract- TR002-sys Assert. E3 ~ Extract- TR003-rel Assert - E4 ~- Extract- TR004-rel

Derive j TR051 -tp ~ Rehne ~ T R 0 5 1 1 -tp Derive - TR052-tp 1 Extract- TR005-tp .( ' Derrve - TR053-tp

Extract - -+ TR006-tp ~ Rehne - TR061 -tp Derive Extract- TR007-tp ~

Replace

TR05 1 2-tp

Rehne

/ i

Jim Assert A-. E5 Assert ~ + E6 Asserf - E7 6 Extract- TR008-tp TPOOl -trace-back ~ Test - 1

PartOf /

PS

R003-trcke-back I

Specily

c SPEC-trace-back

F i p r e 6. Derinizg and Y e j n i z g reqz-iii-emmts iii TOOR.

changes arise not only from changes in die social context of die system, but also from improved understanding of con- suaints and tradeoffs as system develop-

iiient proceeds. Moreover, the system and its requirements coevolze with the social context in that each affects the evolution of the other.

Deriving and refining requirements. T h e process of deriving one requirement from another iiiay be described by a relation called Derive. Figure 6 shows

JECTS AND RELATIONS

Object and relation classes have unique identifiers. The set of object class and relation class identifiers are denoted I,,, and i,,, respectively, with I,, n I,, = 0. The set of all class identifiers IS = io, U I,'. The set of object and relation identifiers are denoted io and I,,, respectively, with I, n I, = 0 The set of all object identhers is denoted

en project at a given stage, it is part , defining the classes of items and n recording the project

= I, U I, . The set of class

1-1 When developing a project, you may use or produce artifacts whose clays iiotations on paper, for example. But such an artifact cannot be traced. On the other hand, the set of object identifiers is

not part of the project specification -

1 , modified whenever an obiect is created or removed. Because of the correspoiideiice between objects and their identifiers,

en use identifiers to refer to objects. The saine applies ses and their identifiers.

For each relauon R c A x B that we want to consider, a

Definition 2. A co?zjgmtzon state

set of arrov s, L IS the set of labels from E to S giving each and U, is a functlon from such that:

= I" U I, . + For each relation object Y E I,,

source and target respectively, there such that i.&J = ol, vl(r,) = zo(t,) = Y,

+ The set of labels consists of th For each object o of class C, the label of the node is the name of its class. vul(o) = C.

I

objects in a way that aausfies the following:

Proposition 3. A configuration state S accura the corresponding confipratlon of objects an TOOR in the sense that

+ For every object o of class C, there i s a ii thdt O,(U) = C Conveisely, for every node a in there is an object o of class C.

+ For every relation R c A x B there is a node /* t N, and arrows s,

+ U"(\? ) = x, V1(S,) = U" (t, + V I ( / * ) = R, u,(x) =A and vr(y) = B.

+ v ~ ( J J = vo(tt ) = r, ~ " ( 7 , ) = x, zii(t,i) =y, an + vi(?:, = R, vI(x) = A and vI(v) = B,

there is a relation R c A x B such that (x,y) t R.

Conversely, for every node Y an

1. For any mathematical relatioii R c A x B, t R if and only if there is a unique relation

ii object represent-

'ts and relatioiis in

th arrows denot- and with labels for Configuration states as texts. Given a configuration state S =

M A R C H 1996

three new requirements derived froin TRO 0 5 ~ tp . A single requirement can be regarded as derived from several 0th- er\: For exainplc, TRO 5 1 ~ tp is derived from T R O o 7 ~ t p and T R o o 5 ~ tp. Requirements can be made more specific by refi?iement, represented by the relation R e f me. Figure 6 also shows three instances of refinement.

T h e difference between require- meiits derivation and requirerncnts refineinent relates to the notlon of satls- faction. If a requirement is satisfied. then its derived requirements should

also be satisfied; however, satisfying a derived requirement does not mean that the requirement from which i t was derived is also sausfied. For refinement, the converse holds. If m e requirement refines another, satisfying the refined requirement implies the satisfaction of the origiiial requirement.

the original requirement, a1 though some other effect of the change may be registered. For example, suppose that the requirement TRO 5 11 ~ tp in Figure 6 was edited to correct an error, such that the original was not retained. A new instance of the Support relatmii can be used to indicate that this change was authorized by Tom.

T h e original form of a changed object can also be kept, by using I he relation Rep lace ; this can help if ques- tions about the change arise later. Of course, the replaced requirement will

Changing and abandoning requirements. Requirements can be changed in vari- ous ways. For example, an attribute inay be changed if a mistake is discovered. In such a case, there may be no record of

(lob, E, I,, U(,, Z ~ ~ , U ~ ) , it? c o n j i p m ~ t o ~ z g~*mzma/- G5 is (A'S, V, X , F ) , where V = IObuIl, 15 die alphabet, A!S = {X, Z, W) is the set of nonterminal symbols, Xis the initial symbol, and

described by regular expr

Definition 5. Given a CO

x+o, Y+ wi; w+ o1 x--t Yo, Y + 27, z + Yo,

are the production rules i n F. The symbol o,, for object identifiers, ranges over the elements of I,,, such that there is one production rule containing o, for each symbol U, in lob{. Similarly, Y, ranges over the elements of I,'.

This grammar specifies the valid strings for referring to objects and relatlons, constructed as follows: starting from the initial symbol, replace the right side of 4ome prodiiction rule for the nonterminal symbol at the left side of that productlon rule, and finish when the string has only terminal symbols in it. For example, the string o,r,o,v,o, is constructed as follows.

E XOs for each node 0, E &,, one state x, E X , for each node o

E I , , one State ~~, the inltlal state, + F = X,,,, the set of final states, + V = IOb7 U I,,, the input alphabet of object and relation

, 6: class identifiers, and

~ 2x, a filnctlon defined by

x+ Yo, +z2;*03 + Y02?*03 + Wt1o2rro3 + U , } , o p ? o j

The inhutive meaning of a string 01?',02 is that object o1 is

where, for any x ' E Xtibl, the corresponding node for the Object ldeiiufied by o* E 'Ob / '

The appropriateness of using the configuration automata related to object o2 by relation ?el Of course, not all strings can refer to a gvven configuration State even strings. For example, O , Y , O ~ is a valid string, but objects o l and

are to talk about config-urations of ob~ects ~ n d relations 1s guar- mteed by the followlng:

o2 may not be related. 'The following iiotlon 15 used to define Proporifion 6. Every strmg recopzed by a coiifigwauon auto- ' which strings can refer to a given configuration state.

maton A, can be generated by the configiiratmii grammar G,. Definition 4. A string s,c, ... s,, c o ~ z f o m ~ to a given configura-

Proposition 7. A string rgl ... s,, conforms to a configuratlon state S if and only if it can be recogniled by the correcpond- ing configuration automaton A,.

strings recogniLed hy A. Therefore, by the above proposi- tloiis, the language accepted by the configuration automaton A, consists of all strings you can use to refer to objects and relatlons in a configuration state S.

tion state S if it is generated by the associated configurauon grammar and there are nodes oo, ..., 0, E Ios such that:

+ = o,, no(e) = o, U,(e ) = o,, for SOIlle e E E, for = 0 inod TThe language by an autoinatonA set Of

2, t = 2, ..., n; and + for some e E E, for z = I mod 2, z = 1 ,..., n-1.

Configuration automata. These are used to match patterns

%Bam


not appear in the final specification document; it is considered nhnadonrd, hrrt remains available for tracing.

Another kind of abandonment occurs when a requirement is later found to be unnecessary or improper. You can either delete such a requirement - losing all trace of it - or inark it as abandoned to preserve it for future reference. Tlic first option is usually takcn near the beginning of a project, when requirements are most unstable. T h e second option is described by the relation Abandon, with the constraint that a requirement can only be related by Aband-on to itself.

T h e graphs in Fig-ure 7 show sihia- tions in which deleting and abandoning re qui r em en ts affect re1 at e d objects . 'TOOR can differentiate between links made by users and those generated by axioms. W i e n you delete an object in 'TOOR, links to the deleted object are also deleted, as are links generated froin tliern. T h e same applies to ahandoning a requirement: both its immediate links and its computed links are autonutically abandoned.

Other aspects of evolution. A requirements specification document states a set of requirenients agreed to at some specific time; it inay represent a land- mark in the development effort or a contract between some interested parties. In any case, producing a require- incnts specification document does not freeze requirements. As development proceeds, new ideas, design diagrams, specifications, code, and so on will be produced. This generates new objects and rclations and inevitably modifies thc requirements.

A11 this happens in a nonlinear, dynamic way. We do not have space to discuss details here, but we can say that

TOOR deals with emlution in a uni- form way Classes are declared for each kind of artifact and reh ion v-e u-ish to control. T h e n particular objects and relations of these classes inay be created and registered in the TOOR database. Figure 6 s h o w some objects and relations used in later phases of derelop- ment: 8 ~ ~ 0 0 1 - z r z c e - 3 z c i and S ~ ' S C - trace-back are a test procedure and a s p e c i fi cat i on t e s t , r e s p e c t i ye ly, for requirement ~ 1 2 2 3 -;rzce-back.

T h e framework in which the project is carried out can also erohye; in TOOK, this means that the project specification can change:

+ X new class inay be created, to register items not prex-iouslj- consid- ered.

t S e w attributes rnii!. be created for existing classes, to re9ister new lands of property.

+ A class ma!- be deleted. t An attribute ma!- be deleted. t Axioms ma>- be changed to

reflect new 1-iews of relations and their composition.

All these changes are easily accom- modated by changing the FOOPS code in the project specification. Creating a nem- class that is it superclass of some existing classes requires all subclasses to inherit its attributes. In TOOR, the templates for al l affected classes are modified by adding die inherited attributes. Objects that are already registered get default values for these new attributes. Default values are also used for already registered objects when a new attribute is added to an existing class. After modifying the project specification, the project should be reloaded so that the database can be recomputed to effect the necessary modifications.

Interpretation of relations. Requirements

evolution is a critical aspect of software development, so appropriate support for evolution s e e m crucial to the success of any traceability system.

Notice that we did not suggest any particular model for software development. T h e relations we described could be part of such a model, but they are by no means definitive. T h e point of the project specification is to let each cul- ture, organization, and team of practitioners support its own values and prac- tices by defining their own classes of objects and relations and interpreting diem in their own context.

Of course, some relations may have a veiy precise meaning, such as refinement for mathematical specifications. In such a case, it is even possible to require a mathematical proof whenever one specification is registered as refining another. 'This can be done by creating special attributes in the corresponding relation classes to hold the proof. You could even require that a proof checker accept the proof before the relation is registered.

On the other hand, relations that do not have precise semantic definitions are necessarily culturally interpreted. For example, what does it mean for a requirement to be Extracted from a document? Is it that the document contains a statement of the requirement or does it suffice to provide some evidence? If so, what degree and kind of evidence is sufficient? The same holds for other relations. For example, what does it take to be able to assert that John Supports a given requirement? Precise definitions can and should be sought, but the decision as to whether a particular case fits the definition is still a matter for interpretation.

Informality happens in software development - it can even be helpful,

M A R C H 1996

particularly in the initial stages. If a given relation is considered too vague, you can choose not to register it in TOOR, but you cannot avoid using it in real life. ’I’hc question we must ask then is: Which informal relations should be documented, and how much is manage- able? Once a decision is made, TOOR can help by providing a database with automatic checks and annotations and with convenient trace mechanisms.

TRACING REQUIREMENTS

So far, we’ve presented the path from a problem statement to a requirements Specification document and beyond in a rather linear way. But this is not how things really happen. During software dcvelopment, there is often as much lateral and reverse movement as forward movement. For example, there may be multiple hypotheses, false starts, experiments, dead ends, and so on. Tracing in such a dymamic environment is seldom straigh tfomard.

Deciding to trace something involves some situation. In a system with inany thousands of interrelated objects, get- ting all the information available may not be useful. There inay be so much information that the configurations before and after tracing are almost the same. Selective tracing is necessary in such cases. However, the criteria to be used in selecting information may not be so clear. A user can often get valuable insight by browsing around, guided by experience and background. Browsing can be constrained to objects connected to a certain selected point. In other cases, the user may be able to make very precise selections. To support a variety of situations, TOOR provides the following three trace modes:

4 Selective waciizg restricts tracing to certain selected patterns of objects and relations.

+ Iatemctive tracing allows interactive browsing through the objects related to a selected object. ‘I’he choice of back-

ward or forward tracing can be changed at any time. A backtracking mechanism makes it possible to return to any previous point in the trace.

+ Nonguided tracirtg allows a user to go from one object to another a t will, inspecting contents as desired.

Selective tracing. Tracing with regular expressions over an alphabet of object aiid relation identifiers uses a language to express patterns of objects and relations. T h e box on pp. 58-59 presents notions for describing how a given configuration of objects and relations can be viewed as a text. These notions are used in the formal development of our traceability model, which incorporates

+ A con$gu?-ation state, which consists of objects aiid relations rnaiiitained as a graph.

4 A co?@,-ur-iztion gira.a7nvTair, which defines the valid strings for talking about configuration states, as described in the section on Configuration states as

4 A con&z~~*ation automaton. For a given c,:Tfiguration state S, a con$gwa- tion automaton As is generated to recognize all possible strings that can represent parts of configuration states, as described in the section on Configura- tion automata. Thev are used to match

text.

trace-back, and that people analyzing that divergence want to know what original documents relate to the specification, to understand the causes of the divergence. The first regular expression produced might be

< n u ~ ~ ~ ~ ? ~ ~ e ~ t z ~ z > * S P E C - trace-back

where <Document> selects any document identifier, and <Relation> selects any relation identifier. T h e iterati’on symbol, asterisk, allows any chain of relations. Given relations y1 and ?**, the expression ~ ~ i p ~ expands to r l ( o l + .., + o,)r2, so the regular expression above is really short for

(dl + ... + d,,)(r, + ... + rIJ((ol + ... + o;)(rl + ... + rI1,))* SPEC-trace-back,

where o l , ..., 0, are object identifiers, dl, ..., da are object identifiers of class Document, and Y~,..., ?’?* are relation chis identifiers.

patterns described by regular expres- I Because PS and the s ta tements sions. I El ...., E7 are the o n h documents, the

A regular expression 7- denotes the language consisting of all strings that match the pattern described by Y . Given

result of matching the regular expression above is the chain of objects and relations from them to the specifica-

a regular expression Y, there is an automaton A, that accepts the language denoted by r. T O O R uses both the configuration automaton A, and the

tion text SPEC-trace-back shown in Figure 8.

Although this reduces the number of objects and relations and give<; a

~

regular expression automaton A, to find the strings that are in both languages. T h e basics of regular expressions are

more focused view, i t still gives too much information. Thus, we wish to narrow the search further. If we sup-

omitted here, bu t the examples should 1 pose statement E 6 is more relevant be enough to make clear their use in our ’ than the whole document, then the context. The examples below are based , regular expression on the configuration state described in Figure 6. Suppose there is a divergence between the specification and the test procedure for requi rement RO 0 3 -

< ~ 6 > < ~ ~ ~ ~ ~ ~ ~ ~ z , ~ @ @ ~ - t ~ a c ~ - ~ ~ ~ = < ~ p ~ ~ z f i i , SpEC-trace-back

would be appropriate. Figure 9 shows


Derive - TR051 -tp ~ Rehne ~ T R 0 5 1 1 -tp I

/ Replace / f 1 Extracf - TR005-tp

Extract - TR007-tp ~ Derive . f

TR0512-tp

Refine I

t R003-trace-back

PS Specify SPEC-trice-back

F i p r e 8. Stavt ofa focusedseavch, 7*eveabi?g the chain of obects and relatiomfiom P S to the speczfication text SPEC- trace -back.

~ TR051-tp ~ Refine ~ T R 0 5 1 l - t p I , Replace

E6 Extract- TR007-tp -- Derive c

TR05 I 1 2-tp

Refine i

R003-trace-back

c SPEC-trace-back

sp&c;r,

Figure 9. Results of a nawow search that focused o n statemeut E 6 and the obects related to it.

the result of searching with i t . This provides more specific information, showing only the objects related in some way to E 6 , requirement R003- trace-hack and specification text SPEC-trace-back.

In using regular expressions to search for patterns of objects and relations, the user can fine-tune the search by giving additional properties that must be satisfied. For example, if the class Requirement has an attribute priority that has values of h igh , medium, and low, then the search for all requirements related to document PS tha t have a high pr ior i ty is expressed as

PS ~ ~ ~ ~ ~ z > * < ~ e ~ / ~ z ~ ~ ~ ~ f f ? ~ [ i ~ r i ~ r i ~ = high]

Operators such as relative comple- ment and logical “and” can also be used in describing patterns of objects and relations, based on the use of Boolean functions to extend regular expressions.

T h e result of a regular-expression query is no t usually a single object identifier, but rather a set of strings, each having multiple object and relation identifiers. A T O O R user types a regular expression in a window that pops up when he clicks on the selective-trace option. T h e n the regular expression is evaluated and its result is presented as a graph with objects as

nodes and relations as arrows. You can inspect the objects in this graph, and you can even start new traces n-ithin this m o r e res t r ic ted context . Fo r example, you can choose t o do a hypertext browse starting from any object in the graph, or you can initiate an interactive trace.

Interactive tracing. TOOR’s module system supports nax-igation from any object to its associated module and from any module to modules containing related objects.

Whenever a T O O R object o is created, an associated module o-rnod is automatically generated, declaring that object with its class and object identifiers. For example, document PS has the module

tmod PS-mod is extending TOOR-SPEC . P S : - > Document .

endt

T h e module TOOR-SPEC is imported into every T O O R module; it contains the specification of T O O R with all its classes, relations, and axioms. The keywords tmod and endt open and close T O O R modules and are used to intro- duce objects.

When two objects are related, their associated modules are updated, each one importing the other as well as the

module associated to the created relation instance. For example, after PS is related to ~ 1 , the module PS-mod becomes

tmod PS-mod is extending TOOR-SPEC ,

protecting El-mod . protecting PS-El-mod PS : - > Document .

endt

T h e module El-mod contains the dec- larat ion of the object EI of class Statement. T h e module PS-El-mod contains the declaration of the instance of relation Partof, relating PS to E]

T h e interactive trace mode uses this facility to follow chains of imported modules from any given module. T h e user can choose among the following interaction modes:

+ from module to module + without interruption, and + place the results in a file that can

be browsed afterward. Alternatively, the results can be

shown step-by-step, making it possible to control which objects (modules) are interrogated next. For example, tracing requirement TRO 5 11 - tp backward in an interactive mode without interruption would yield:

TR0511-tp is related 1) by Ref ine to TRO5l-tp, which

is related 1.1) by Derive to TR005-tp,

M A R C H 1996

OBJECTS

RELATIONS

I

$

i Document URL.

2 Document Title

@ I

I

$

i Document URL.

2 Document Title

@ I

TOOR MODULE DESCRIPTION

Module Name: TROOS-tp-mod

imported modules:

4 PC-1n.l 4 TR F- tp-mod

4 TF ':-tp-mod TF,,C--tp-m~~d

principal object: TROOS-tp

requirements:

other objects:

4 1 i iiment r-2

relations:

4 E-: Extract TROO5-tp x "

Figure 10. Sample TOOR scveen showzzg the bypetmedia zeuion of module TR005 - t p coatazmzg all the modules it impoTqs, ithe oljects that are dwectly accessible ?om z t , and the ?-elatzons amorag- them.

which is related 1.1.1.) by Extract to PS

1.2) by Derive to TR007-tp, which

1.2.1) by Extract to E6, which is

1.2.1.1.) by Assert to Ji.m. 1.2.1.2) by partot to PS

is related

related

2) by Support to Tom.

Nonguided tracing. TOOR has a free- trace Inode that is convenient when you have little information on what or how to trace. Th i s mode supports functionality analogous to browsing through a book: You can search for something seen, for example, some- where near the middlc of the book, probably near the bottom of an even- numbered page. In this mode, a main graph window shows objects and relations as nodes and arrows, while a list window shows object identifiers; each window allows some choice of how objects are displayed. In the list window, the user can choose to view only

objects of a certain class. T h e user can also choose what classes of objects and relations are to be shown in the graph window. In each window, the user can select any object to view its internal structure. Another possibility uses a hypermedia tool - at the moment, Mosaic. T O O R maintains an H T M L version of each object and updates the links as re la t ions a re created and destroyed.

Figure 3 is a TOOR screen whose graph and list windows show some objects and relations from our example. 'The small window a t the bottom is a template for the relation. Figure 10 shows the module for the object TRO 0 5 - tp , with all the modules that it imports, the objects that are directly accessible from it, and the relations among them. This module appears in a Mosaic window t h a t popped up when the user clicked on the hype?" option. By following the links in the hypertext version of a TOOR object, you can access its original format,

which may be a sound or video clip, a design chart, or information stored in some other medium.

Discussion. Trac ing with regular expressions provides a context for the selected information. When giving: a pattern to be matched by objects related in a certain way, the user narrows the original context of objects and relations to those most relevant to the given situation. Then he can define a new, narrower, context based on what he learned. T h e context that results f r o m matching pa t te rns can be changed not only by changing regular expressions, but also by changing the axioms that define existing relations. T h e use of a regular-expression language for tracing is justified by its con- ceptual adequacy, its simplicity, and its efficiency. Adequacy for the most common and natural si tuations is achieved by using the additional features we've described, such as clztss names and FOOPS axioms.


e designed T O O R mainly as a research tool to explore ideas

for improving the requirements phase of software development. Requirements traceability is the primary research topic, but the scope of the tool reflects our view that requirements issues are pervasive and occut throughout the life cycle. Therefore, requirements traceability should be available at all times, and traceability of any desired artifacts should be supported.

Most features of TOOR are already implemented, and several case studies are being developed to demonstrate its capabilities. Nevertheless, we recognize that real-world applications are needed to show its adequacy for real-world problems. We’ve already taken the first step by applying T O O R to an undoubt- edly large and difficult problem: its own development. Our initial impressions

confirm our belief in TOOR’s feasibili- ty; a thorough assessment will be presented elsewhere.”’

Much of our approach relates to effective information rnanagernent. T h e hypermedia capabilities of T O O R make it appropriate for use in the beginning of a project, when infornution in different media is most likely to be encouii- tered. TOOR is also appropriate for design, in which graphics plays an important role. That T O O R modules are related to FOOPS modules makes the connection bemeen requirements and specifications easier. Because FOOPS is a general object-oriented language, there is also a connection between requirements and code.

Finally, the user-definable features through a formal project specification make TOOR an interesting tool for requirements research.

ACKNOWLEDGMENTS Wc thank Jawed Siddiqi and the anonymous referees for their vel?- helpful comments.

Partial support for this work was provided by a research grant from CXPq under ccintract number 200666/91-6; British Telecommunications plc; the C E C under Esprit-? BRA Worlung Groups 6071, IS-CORE and 61 12; Compass, Fujitsu Laboratories Limited; and a contract under the management of the Information Technolog)- Promotion .lgenc!- (IP-L), Japan, as part of the Industrial Science and Technolo,yr Frontier Program “Sell- IIodels for Software Architectures,” sponsored by NED0 (New Energy and Industrial Technolop Development Organization).

REFERENCES 1. J. Gogueii, “Requirements Engineering as the Reconciliation of Social and Tech~ i~ca l Issue

Requirements Engineemzg: Social and Technical h i e s , .U. Jirotka and J Goguen. eds., ica i le i i i San Diego, Calif., 1994, pp. 165.199.

2 . J. Goguen, “The Dry and T h e Wet,” in Inji~imnrion S’r~~717.r C o i i q t s , E. Falkenberp. C:. Rolland, m d E.N. El-Saycd, eds., Elscvter, North-Holland, 1992, pp. 1-1 7 .

3 . A. Socorro. Desig7z, Implementation n77d Evabutioz of[/ Decliii-ntix Oli/ei.t-Omntcii Pi.op7ni111ug Langzifigc, doctoral dissertation, Oxford University Computing Laborator!, Oxford. UK, 1993

4. J. Gogucn and J . Messeguer, “Unifying Functional, Object-Oriented. and Relational Programminp with Logical Semantics,” in Research Di~ectzovs i71 Ob/rct-Onented Pn~gi.a71i7niij,y. B. Slirix-er dnd P. Wegner, eds., M I T Press, Cambridge, Mass., 1987, pp. 1-1 7-477.

Winter School on Abrwact So~uare Speczficatiu7r, Springer-Verlag, Berlin: 1980, pp. 292-332. 5 . R. Burstall and J. Goguen, “The Semantics of Clear, a Specification Language,” PJ-OC 19-9 Copeiibngim

6. J. Goguen, “Reusing and Interconnecting Software Components,” Conipiirer, Feb. 1986, pp. 16-28. 7. J. Goguen, “Principles of Parameterized Programming,” in S o f i g a m Reiunbility. V o l i m i e I: Concepts and

Mudelr, T. Riggerstaff and A. Pedis, eds., Addison-Wesley, Reading, Mass., 1989, pp. 159-225. 8. J. Gogueii, “Hypcrprograinming: A Forinal Approach to Software Envirmiments.” Pi-or. Sy777p. Fonnnl

Approaches t o So f ia i v Enviro7zment Techmlogy, Jolnt Sy\tem Developrneiit Corp., T i~kyo , 19911. 9. Luqi and J . Goguen, “Formal Methods: Promises and Problems,” 10. F.A.C. Pinhciro, Deszgrz of a ~ly)er-Ei?vivon7ne77t~i, T7-areabzlity of O~~iecr-O7~1ei?tecl Regiiirenzents iii

System Development, doctoral dissertation, Oxford University Computing Laboratov, Oxford, UK, to appear.

Francisco A. C. Pinheiro is a doctoral snldeiit a t Oxford University. IIe has been a systems analyst, project leader, system manager, m d company manager for xveral Brazilian conipanies aiid has been involved in the development of large sys-

tems for hoth private a n d government companies. Piiiheiro received a BSc in niatheinaticshfor-

iiiatics from the State University of Rio de Janeiro aiid an MSs in (:ompiiring Science froin the University of Brasilia.

Joseph A. Goguen IS a professor in the Dept. of Computer Science and Rngineerrng at the Univer- sity of California at San Iliego, where he is the director of the Program in Advanced Manufacturing. He is on leave from Oxford University, where he is professor oicomputing sci- cnce, director of the Centre for Requirements and Foundations, fellow of St. Anne’s College, and a iiicnibcr of the Ovford Uniyersity Coinpnting Lab’s Programming Research (:roup. He was a senior staff scientist at SRI International i n Menlo Park, California and n senior member of the Center for the Study of Imguage and Information at Stanford University. (+yen is the author of more than 160 publications and several books. He is an cditor for the Cniiibritlge University Press ‘1‘1-acts in Theoretical Computer Science, executive editor for one professional journal, and rncrriher of the editor- ial boards of seven others.

Gogueii received a KS and an MIS in niatheniat- ICS from Ilan-ard, and a PhD in mathcniatics from the tiniversity of C:alifornia at Berkeley.

Address questionu ahout this article to Pinheiro at Oxford Univevsity Coinputing Lab, U’olfsoii Building, Parks Road, Oxford OX1 3QD, UI<; [email protected]; or Goguen a t Dept. of Camputer Science and Engineering, University of Califomla at San Diego, 9500 Gilnian Drive, La Jolla, CA 92093-0114; [email protected].

M A R C H 1996

mailto:[email protected]

an object-oriented tool for tracing requirements

Documents