SOFTWARE QUALITY THROUGH THE TRACEA OF REQUIREMENTS SPECIFICATIONS

T. T. Moores and R. E. M. Champion

Department of Information Systems, City Polytechnic of Hong Kong,

83 Tat Chee Avenue, Kowloon Tong, HONG KONG.

Abstract - This paper will argue that quality

assuranoe‘ must begin with quality software

requirements specification (SRS) and that by

preseming the link between a customer’s

requirements definition and the SRS, the quality of

a software system can be assured beyond first

release. Without such a link, i t would be difficult

to properly analyse the effect of related or

inconsistent requirements because the reason for

their existence in the final SRS document has been

lost. An example of forward and backward tracing

requirements through the business and system

models developed during analysis and design is

given. Areas of further research are then

identified.

L INTRODUCTION

Proper means for assessing the quality of a software

development product or process has yet to reach a mnsensns.

Definitions of software ‘quality’ have ranged from hierarchical

d&nitions[l,2], where quality is M i as a range of related

propezties such as “usability”, “efficiency”, etc. The problem

with such a definition is that many of the attributes are related

to each other (e.g., reliability and usability), while the list

tends to he incomplete Other attempts to defiie quality have

emphasised the competing views of customers and developers

as to what’s importaut[3], where ‘quality’ often becomes a

question of the .product matching user needs[43. This

a p p r d to quality demands that the pmducis and processes are

amenable to cbaoge in order to match the changing demands of

user mpireanents, both M u g and after the construction of the

Software lqlirements specification (SRS).

ThIs paper will argue that a quality system begns with

a quality software requirements speaficahon (SRS), and that

the quality component acheved at h s point can be mantinned

throughout the development process by ” g n g the effect of

changes on the requirements The authors believe that this can

be ache>& by retainmg the business and system models

de>eloped dunng system analysis and design and mmntaimng

the links between requirements statements and implemented

funchonditj In this sense, it is the ‘meetmg customer needs

and espectahous’ defimhon of quality whch is h u g used here

By linking requrements to subsequent products, it would then

be possible to analyse the effect of requirements changes by

traang thew effect throughout the entire life-cycle Thts would

allow the consistency of any new reqwrements to be checked

(fonrard traang), as well as the consistency of change and

nmutenance requests for the implemented system aganst the

ongnal stated business goals and processes (backward b a n g )

This paper will demonstrate the feasibility of mautrumng such

traceability, and illustrate the process with an example

II. REQUIREMENTS ANALYSIS AND DESIGN

MODELS

A requirements document is the mhal expression of a

customer’s reqmments for an mformatzou system, wntten in

natural language Understanding the content of the

rquremeuts document is (often noted to be an art) referred to

as requrements analysis This stage of the life-cycle attempts

to convert the natural language expressions (or customer “wish-

list”) contained w i t h the reqmrements document into more

rigorous representations of the requred system Two important

sets of models used in the requirements analysis and design

phase are business and system models Figure 1 represents the

relahouslup between these models.

, 0-7803-2608-3

100

Figure 1. The requirements-analysis phase

It should be noted that while relationships also exist

between the business models and project “agement models

(such as GANTT and PERT), these are not discussed within

this paper and so are not represented in the model.

Business models include those of the organisation,

business process and business rules, and are needed in orda to

understand the context in which the information system is

required. The organisation of a company represents the

structure that is imposed on the individuals in their execution

of thk Wks necessary for the functioning of the business.

Typically, an enterprise will be organised into a hierarchy or

network of specialised subunits, aud organisational hierarchy

diagrams may be used to model these.

Within the context of a particular company, a business

process is the set of tasks by which a company seryes an

internal or external customer and has a w e l - d e f d outcame or

set of outcomes, such as manufaEturing, marketing or des.

Models for representing business processes will typically use

dataaud resouTces flow diagrams. Busihess rules are specified

for the efficient operation of the business procaw and m

usually written docwnents developed by the organisation to

their own standards.

System models represent the solution space for

information systems implied witbin the requimne-ots document and use techniques which take a particular view. For instance,

a functional view may use data-flow diagram (e.g., [6]), a data

view may use entityrelationship diagrams (e.g., m), a

bebvionral view may use state charts (e.g., [8]). while an

object4ented view may use a synthesis of these techniques

(e.g., 191). The problem with these kfferent system views is

that they me selective about the type of i n f o d o n which is

repesenteil, while a complete view of the system may well

require more than one view to be taken. As such, recent

research has attempted to translate between these

techniqua[ll], and provide traceability from one f d model

to auother[l2].

The systems analyst is the person who carries out the

process of transformation from business to system model. It is

the job of the analyst to act as a “sieve” from the natural

language expression of the requirements to a represmtation of

the system in terms of data-flow models, logical data

structures, etc. The form and content of the system models are

checked for consistency against the business models. When the

customer is satisfied that the business models propaly reflect

the business, the analyst can verify that the system models are

consistent with this view. The result of this activity is a

software requirements specification written on the basis of the

business and system models.

The intermediate business and system models, however,

are typically viewed as ‘throw-away’, conl?ibuting simply to

the constrnction of the SRS. In the next section we will argue

that by preserving these intermediate models, the problem of

checking the consistency of new quests/requimuents bearmes

101

easier.

possibiliq of measuring the quaIiq of the

development process, from reqpin“ts document to

With snch haceabilty in place, thae is (hen the

operational system.

HI. TRACING REQUIREMENTS THROUGH

ANALYSIS AND DESIGN

The snggestion to be made here is that since the d j - s t

must analyse the customer’s reqpkments in such a way that

the system models can be bnilt, &ere exists the possibility of

capturing the link between any part of the s$tem d (conshucted by the analyst), and any part of the business model

andrequirements doameat. his is becau~e t& d y s t must

perceive some part of the reqninments doaanent as an

expression of some functional requirement which is then

represeated in the system model. R‘i’ithout sllch a link, there is

no reason for the system model component to exist. This link

is represented in Figure 1 by each arrow.

when a change reqnest arrives, if the bnsiness d

system models are not retained it would be impossible to checg

the consistency of the request properly. This is becanse the

process of filtering and refining ihe mpimnmts doaawnt

towards the SRS has been lost If the models am retained,

however, it should then be possible to I%-: . whether the

change reqnest d d s which any part of thebusiness models.

If it does, then there will be a need to either:

reject the change request, became it does not

contribute to the stated organisatid or business

goals or objectives, or;

revise the business models, becanse ihe busiwss

models were shown to be incomplete b> the nem

chaogerecluest If the change request does not conflid with the b u s k s

models then it can be accepted as an additional r e m t .

Theneed then is to see if it relates to any Omer aka& stated

requirement. If i t does, then traceability wiU allow the d y s t . todetemme which part of the SRS needs to be changed to

mcorporate the new request. The following example iltnstrates

the process of fd&g infonuation s y s t q m s . r e q m s

through the business models, pior to their ~ m o n in

the systems models

A target information systemis tobedekgued to soppoa

the mannfachmng process of a company speaalrsing in sports

wear Part of the functionality of the sjstem is intended to

asmst m the a~tlvihes of predictmg demand for raw matenals,

and selecting swtable kendors It is intended that vendors will

be selected pnmanly on the basis of pnce quotatmns for the

quantities currentlj rqured The business model denved from

the anal)sis work will lnchde an organixihon herardly

shouvig the relatlonshp between production and purchasing

departments These are to be the p n m q customers of the

described functionality Analysis of the business d e s

asscxratd wth these departments has re\ealed the following

three rules among those felt to he relevant

“Qnauhhes of raw matenals ordered for each

monthll cycle should not exceed 1207 of estimated

demand for that month ”

“A vendor nil1 k. considered to be iinsabsfactorj If

the3 fad to deliler on time for two successive

orders ”

“A sati\factor) sendor will be chosen for a p e n

order i t thar pnce lor the spedicd qtlantztj of the

r a p r e d product is lotrer than all other satlsfactory

‘L endors -* I

An example of a requuement for the mformatmn slstem

mght be that the system will p o i idc the purchasing manager

with a list a 1 endors for a ~ 4 % en product The business models

(in particular ndes 2 and 3) wtll add to the rtyresentation of the

reqwement in the sjstem models, hj necessitatlng the

inclusion of hstoncal data on iendors’ deli\ er) times (nile 2),

and the mclusion of +anable pnce quanut) rather than one

pnce per product per tendor (rule 3) In a w ~ l a r may, the

process model for the target infonnatlon s)stem sill be affected

by the business model components Fonmng the list of

vendors must include a check on the status of each i endor The

smgle reqlurement statement IS thus Ctffused in the sjstem

models, and needs to be linked to the busiiiess models to allow

tracing through these models Figure 2 belou shows this

&ffusion

Subsequently, ad&tlonal funchonality may be q u u d

by the p n r c h n g manager The new reqlurement may be for

the system to provide assistance in the selechon of a vendor for

a given quantity of a gtven product T h ~ s will now invohe the

Conslderahon of rule 1, whch allow the effect of increasing

the quantity ordered on the mt pnce to be included in the

102

system. No Connict cau be detected with the current business

or system models, and so the requirement may be

accommodated.

Figure 2. Diffusion bf requirements from initial statement to

system model

Fibre 3. Rate of change of system requirements specifications

Q: Once the initial system requirements speCificatiw has been agreed, how often are there changes to these requirements during development?

50s 47%

U

Rate

Backward tracing - from change reguests after the SRS

or system ha^ txxn produced to the business models oT initial

requirements document - is a vital process given the propensity

for customer’s to chauge their requirements. For instance, in a

survey of large UK corporations and computing companies by

e c w I n @ E $ ~ t h a t nSerq*ts change most or all of

the rime dming system development (see Figure 3).

complplainds made are thatr€*its are poorly dedined, too

maintenance is @ d v e ( i n e w l l s e r

r l 3 1 .

In the exanople, tbe pacha3ing lllioager may raluest @at the limit (111 plrchasing of 120% of estimate4j denlad be

The main

specolative. or kmplae. Perbps this is why 65% of

m v e d , to allow a 1- list of.suitable vendors to he

presented since it is known that a number of vendors have a

minimm delivay limit A larger v& list w d d allow the

p”6ng “ger to have more flexible n e e powers.

While the system models wiU contain a record of this limit,

In

&is c a e , it may be the case that the business p a w

the~lcati(111win be iwutded in the business models.

.poanmoa’bas mles linked to goals iy“hg the storage of exoessmatexds. Inotherwords,rule1basbeeoimposedon

the prching department as a result of its relationship with

theIEoddonaepaameat. Inordertoanalyse theimpact of

the pmposed change to the systd, backward tracing to d e

in Figne 4.

bpsiness model is vital. This backward tracing is represented

Figme4. Tracing a cbaage request to its impad on tbe business rules

IV. SUMMARY, CONCLUSIONS AND FUTURE

WORK

Thi.paper~arguedthat by retaining awl maintaining

the business and system models used during requ;ements

analysis ad design, it is possible to ensure the consistency of

the SRS docomeOt s u ~ h rhat it meets the changing needs and

e” of the customer. This is the definition of quality

the authors, of 54 replies it was found that 66% of the used throagbont the paper. Without a quality SRS it is not

103

possible to prcdnce a quality system because without sufficient

justifcation for the content of the SRS the consistency of the

requirements remains in doubt and the project is being driven

by poorly defmed needs. In the worst case, the d e v e l o p will

deliver a wellcoded, well-tested failure.

With a quality SRS in place, the business and system

models can then be used to check each request for change that is

ge”& either during the analysis and design stage (and

forward tracing to the SRS document under construction), or

during implementation of the SRS (and backward tracing to the

original system models, business models or. requirements

document). The link between requirements document and SW

is a process already carried out by the analyst, and change

requests are ordinarily reviewed before implementation, so the

techniques described here can support quality SRSs ad

subsequent implementation with little additional work.

The need now is to validate the traceability technique by

implementing a means of capturing as complete a picture of

the business as possible. With this in mind, the authors are

developing an enterprise model which Mines the business

issues that need to be considered. In the model an enteqrise

has a mission which determines a number of business

objectives. Constraints placed on these objectives by the

business environment produce a number of quantifiable goals

xhich are targets for the relevant business processes.

Therefore, the enterprise model will act as a starting point for

determining what is required in the development of business

models for infokt ion systems development. Further

investigation will be aimed at produang process models for the

population and exploitation of this enterprise model.

Einpirid data wsill be Collected from case studies to validate

the stntcture and content of the enterprise model, before

applylug the traceability techniqnes to a live project.

An added value of implementing reqniremmts

traceability is that it would allow an analysis of which type of

qnirements represent a grater risk to systems development.

‘Risk‘ in this sense can be defined as either requirements which

translate into a high degree of functionality, those which are

liable to change, or those which are implemented as

components which a& error-prone. This can be deduced using

software. metria which measnre the number of requirements,

the size of the intermediate products and the size of the final

(opemtional) system. By tracing the effect of rquirements on

aspects of the fmal system, it would then be possible to weight

the cost of each requirement in terms of the implementation

e€fort, number of change requests received, and the number of

errors uncovered during the testing phase. The authors are

attempting to incorporate this analysis in their investigation.

REFERENCES

Mccatl, J. A. et d (1977) “Concepts and definitions of

software quality.” Factors in Software Quality, NTIS,

1.

Boehm, B. et al (1978) “Characieristics of Software

Quality.”Nortl-Holland, New York, NY. Watts, R. (1987) “Measuring Software Quality.” NCC

F’nblications, Manchester.

Gawim, D. A. (1%) ‘What does ‘product quality’ really

mean?’ Sloan Management Review, 26(4)), ZS43.

Kitchenham, B. A. (1989) “Software quality assnrance.”

Microprocessors and Microcomputers, 13(6), 373-381.

Gillies, A. C. (1992) “Software Quality: Theory and

Management.” Chapman & Hall, London.

DeMarco, T. (1978) “Structured Analysis and System

Specification." Yourdon Press, New York, NY. Yourdon, E. (1989) ‘Modern Structured Analysis.’’

Rentice-Hall, Englewood Cliffs, NJ.

Harel, D. (1987) “Statecharts: A visual formalism for

complex systems.” Science of Computing.

C o d , P. and Yourdon, E. (1990) “Object-oriented

Analysis.” Prentice-Hall, Englewood Cliffs, NJ.

Jordan, K. A. and Davis, A. M. (1991) “Requirements

engineering metamodel: An integrated view of

requirements.” In Proceedings, 15th A ~ u a l

International Computer Software and Applicatious

C d e m c e , Tokyo. Japan, 11-13 September, 1991,

pp472478.

Border, J. and Janning, T. (1992) ‘Traceability

behveen requirmaits and design: A transformational

approach.” In Proceedings, 16th Annual International

Compnter Software and Applications Conference,

Chicago, IL, 21-25 September, 1992, pp362-368.

Lientz, B. P. and Swanson, E. B. (1980) “Software

Maintenance Management.” Addison-Wesley, Reading,

MA.

1 04