identifying quality requirement conflicts …ece473/readings/27-identifying quality.pdf ·...

Identifiing Quality-

~ H

Requirement Conflicts

BARRY BOEHM and HOH IN, University of Southern California

Without a weLl-de$ned set of quality-attyibute requirern en ts, sofi;-d.are pyojects aye vulneyable tofiilure. The authors have deve Loped QA R CC, a knowledge-based tool that helps usen, dmelopeus, and customem anaLyze yeguivements and identifj conflicts among them.

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

espite well-specified functional and interface requirements, many software projects have failed because they had a poor set of quality- attribute requirements. Finding the right bid- ance of quality-attribute requirements is an important step in achieving successful soft-

ware requirements and products. To do this, you must identify the conflicts among desired quality attributes and work out a balance of attribute satisfaction. The importance of this balance can be seen in examples that failed to find it:

+ In the New Jersey Department of Motor Vehicles licensing system, engineers chose a fourth-generation language to satis5 software affordability and timeliness objectives, but the system failed because of performance-scalability problems.

+ T h e initial development of the National Library of Medicine MEDLARS I1 system had a plethora of layers and recursions for portability and evolvability, but was eventually

0 7 4 0 7459/96/$05 0 0 Q 1996 I E E E

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 13:22 from IEEE Xplore. Restrictions apply.

2 Identify stakeholders’ win conditions

3 Reconcile win conditions

Establish next-level oblectives, constraints,

alternatives

7 Review, commitment 4 Evoluate product

and process alternatives Resolve risks

5 Define next level of product and process - including partitions

Figure 1. Wzn Win spzral model

Covers Addresses

Figure 2. Win Win negotiation nzodel.

scrapped due to performance problems.

+ l ’he init ial design of t h e hRPANet Interface Message Processor software - which was fortunately revised - focused on performance a t the expense of evolvability through the design of an extremely t ight inner

Because i t had an expert review team, the ARPANet problem was identified early and thus avoided. However, there is an overall scarcity of such software expertise. It would be valuable to capture the expertise that does exist and make i t more broadly available through automated aids that analyze conflicts among sof tware - qua 1 i ty attributes.

VJe have developed an initial ver- s ion of such an aid. T h e Qual i ty Attribute Risk and Conflict Consultant is a knowledge-based tool that can be used early in the life cycle to identify potential conflicts. QARCC operates in the context of the W i n W i n system,’.‘ a groupware support system developed a t t h e U S C C e n t e r for

loop.

Software Engineering to determine software and system requirements as negotiated win conditions. Q-kRCC works by examining qualip-attribute tradeoffs involved in softv-are architecture and process strategies. It may tell you, for example, that a layered architecture will improve portability, but usually a t some cost in performance.

This article suniniarizes our experiences developing the Q-kRCC-1 pro- to type us ing an early \-ersion of Vrin\T7in, and our integration of the resulting improvnients into QAIRCC- 2 . In some cases, t e rminology has changed in the n e x T-ersion; these are noted where appropriate.

THE WINWIN SYSTEM

T o r e so 1v e qua 1 i t y - r e q u i r e in e n t conflicts, you must a t least be able to

4 identify and negotiate quality- attr ibute re quire in en t conflicts and tradeoffs and

4 diagnose quality attribute conflicts on the basis of early information.

TAre use the TT’inTTh system to provide tlie first capahili?: For the second capability, the QARCC tool operates on the win conditions captured by the WinWin system to diagnose potential quality conflicts and tradeoffs among requirements early in the development process.

Figure 1 shon-s the MTinWin spiral model, which serves as the basis for tlie n T i n W i n system. T h e system uses T h e o q W’ to generate the objectives, constraints, and alternatives needed by the spiral model. T o meet its goal of “making everyone a xinner,” Theory

W involves stakeholders in a process of identifying their quality-attribute win conditions (sector 2 in Figure I ) and reconciling conflicts among quality- attribute win conditions (sector 3).

Figure 2 shows the WinWin negotiation model’s primary schemas and the re la t ions among them. Stake- holders begin by entering their win conditions, using a schema provided by t h e Winl;liin sys tem. If a conf l ic t among stakeholders’ win conditions is determined, an issue schei7za is composed, summarizing the conflict and the win conditions it involves.

For each issue, stakeholders prepare candidate option schenzas addressing the issue. Stakeholders then evaluate the options, iterate some, agree to reject others, and ultimately converge on a in u t u a 11 y s a ti s fa c t o r y o p t i o 11. T h e adoption of this option is formally pro- posed and ratified by an agreenzent schema, which includes a check t o ensure that the stakeholders’ iterated win conditions are indeed covered by tlie agreement.

In large systems involving several dozen or more win conditions, it is dif- ficult to identify conflicts among them. T o aid in manual and automated coil- fl i c t as s es sni en t , the win -condition schema includes a slot for associating the win condition with elements of a taxonomy for the system domain.

WinWin also provides - and lets s t alte h o 1 der s t ai 1 o r ~ domain tax - onomies. Figure 3 shows an example for the software-engineering environment domain. T h e SEE domain taxoii- only includes a “domain elements” sec- tion in the center and two relatively domaiii-independent parts: the infra- structure on the left and the attributes on the right. It is this attribute struc- tu re tha t t he QARCC tool uses to identify potential quality-attribute conflicts among win conditions.

For each win condition that identi- fies a desired quality attr ibute, t he QARCC tool uses a knowledge base to identify software a rch i tec ture and

M A R C H 1 9 9 6


\ ts n n ture)

/ \

~ Assurance

t t ~~ ~

Directly-concerns Contrbutes-to Positively/negatively influences

F i p r e 4. QARCC knowledge-base s tmctwe.

process strategies for achieving the quality attribute. For each strategy, it uses another part of its knowledge base to identify potential conflicts with other quality attributes that could arise if the strategy were employcd. It then provides sugges t ions abou t these potential quality-attribute conflicts and options for resolving them.

QARCC KNOWLEDGE BASE

T h e context and information avail- ab 1 e for an a 1 y zi n g qua 1 i t y - a t t r i 11 u t e risks and conflicts early in the life cycle conies primarily from the prioritized

requirements, as expressed by different system stakeholders’ win-condition schemas. Overall, customers’ primary concerns tend to focus on such attributes as cost and schedule, while users tend to be more directly concerned about such attributes as performance and assurance.

As the left side of Figure 4 shows, the Struchire of the stakeholders’ first- o rder interests forms a par t of the QARCC knowledge base, which includes a quality-attribute hierarchy similar to those in previous analyses.’-6 T h e major difference here is that our hierarchy’s highest level is connected to the quality attributes most directly

valued hy the various classes of stakeholders. For example, a maintainer tends to be primarily concerned with evolvability aiid portability and oiily secondarily concerned with develc’p- inent cost, schedule, and reusability, which teiid to be primary concerns of customers and devclopers. This structure cnables QARCC to associate quality-attribute risks and conflicts with the appropriate stakeholders. It thus flags potential concerns and provides stakeholders with advicc for resolving them.

T h e other major component of the QARCC knowledge base, shown on the right of Figure 4, is a set of relationships between software architex-



Maintainer Developer Customer General public lnteroperator User

. , Directly concerns

Assurance I nteropya bi I ity Usyh I ity Per

Interface to

Reliability/ ’ ’ accuracy,

Security/ \ \ Architecture Element ‘\ ,, balance performance

‘,, \, ‘, \ Development Key ‘\ timeliness development -\

\, Correctness / Safety Mission Controllability Verifiability \, Maintainability/ Personnel

I \ orientation \ \ debuggability

Availability,’ Integrity Comprehensiveness Scalability 1 Expandability survivability I

Flexibility Modifiability

ture and process strategies and their usual effects o n quality a t t r ibutes . For example, a layered architecture has a positive influence on portability because a Sayer can hide platform d e p e n d e n c i e s ; i t h a s a n e g a t i v e i n flu e 11 c e on p e r fo rniaii c e because in - 1 in e in a c h i n e - d e p end en t cod e is usually more efficient. T ~ L ~ s , using a l a y e r e d a r c h i t e c t u r e s t r a t e g y t o achieve portabi l i ty will f requent ly cause a conflict with performance objectives.

MAJOR COMPONENTS AND RELATIONS

T h e most frequent stakeholders are users, customers, developers, maintain- ers, interfiacers, and the general public. Others could be product-line maw age r s , t e s t e r s , o r subcont rac tors . Complex systems inay hare sereral different sets of users and customers.

First -order stake holder interests. i Tve determined the pniiian -attribute M in

i’ IDENTlFYlNG QUALITY REQUIREMENTS: A COMPARISON

conditions for each stakeholder role through our experience in applying T h e o r y IV t o complex, multistake- holder projects such as Army WWM- CCS Inforniation System, STARS, and the TVinWin system itself. Figure 5 diagrams how we mapped the stakeholders’ primary concerns to quality attributes. At the top of Figure 5 are the stake h o 1 der s and their p i i mary requirements. Second-order stakeholder interests are also important (the developer cares about usability because

One initial qproach to specifying quality attributes was the Requireinents- Properties Mmix ’ It provided a crowimpact matrix between the software fimc- tional requirements a i d the required properties or attrih- utes, which qerved as a inan- ual framework for identifj- ing derived functional requirernents iniplied by the attribute requirements Several of the Roinc Laboratory Quality Metrics reports - such a5 the one by James A4cCall and his colleagues’ ~ provided check- lists of attribute capabilities to be considered Jn requirements specifications, but did not address automated conflict analysis. A later Konie- sponsored study by Do~iglas Schaus developed a traine-

work for an autoinated assis- tant for specifving quality software.’

Tom Gilb provides a framework for finding and specifying desired attribute levels in terins of solution specification, tagging, hier- archies, modularization, anti cross-referencing, but no resolution aids are proT-ided.’ Steve Easterbrook provides a good conceptual frameu ork for conflict resolution between doniain descriptions with coiiil.’uter-supported negotiation.’ He also provides an approach for resoh - ing conflicts between different domain specifications, and provides an example using a library iiiforniation- system specification. Lawrence Chung and his colleagues provide a good

s!-stem framen-ork for increasing traceability of quality attributes mhen chaqes in quality attributes or their importance, or design decisions and ratio- nale, occur during the development proces6 The system draw on domain knon-ledge to aid in assessing quality attributes, whereas our approach is dornain- independent (although tai- lorable to specific domains).

l e a p e s proT-ide a fiue-step inethod for analyzing software architechires 111- analyzing three separate user-interface architectures with respect to the qirality of niodifiability.’ They use representative operations to analyze the relationship hetu een sofnvare architec-

Rick I<azman and his col-

tures and quality attributes, hut leave open the question of the sufficiency of the representative operations. Kaman and Lei1 Bass explore the relationship between architectural “unit operations” and a method for deriving software architectures from eight quality- attribute requirements.8 They provide a useful first- order conflict analysis of the interaction between the eight attributes, which we have used and extended in our analyses. However, their method of deriving architec- hKeS from requirenients is somewhat oversimplified. Our assessment is that finding the right balance among conflicting quality attributes is too complex for simple algorithms, and that provid-

M A R C H 1996


the user does), but these are generally addrcssed by negotiating first-order stakeholder win conditions.

Attribute elaboration. T h e lower set of arrows in Figure 5 show the next level of detail in the hierarchy. As the figure shows, the assurance attribute, which is a primary coiicerii of users and the general public, m a p have several subattributes.

In inaiiy cases, it is sufficient to rea- son about attribute conflicts at the pri- inary attribute level, but the lower levels are important at times - such as when conflicts arise between fault-tolerance data distribution for availability and restricted data access for security.

Strategy-attribute relations. Table I shows the genera l set o f quali ty- attribute strategies in the knowledge base, o r g a n i m d i n t o p roduc t and

ing options and suggestions for stakeholders and archi- tects i s likely to have a high- er payoff.

The object-oriented design patterns developed by Erich Garnina and his colleagues provide atiditional candidate-attri bute strategies, particularly in the areas of evolvability/portability, interoperability, and reusability.” We are analyzing these to capture exteii- sions to the QARCC knowledge base. Like our WinWin and QiZRCC: system, William Robinson and Stcvc Ficltas provide a model and a tool (callcd “Oz”) that detects and resolves conflicts, and provides an interactive rcsolutioii-choice pro- cedure and records of the negotiation process.’” Their

process strategies. W e de ter mined these strategies as a result of reviewing and filtering numerous studies of indi- vidual and multiple quality attributes.

Table 2 shows the elaboration of several architecture-based strategies for itiiproviiig quality attributes, including top-level assessments of their effect on other quality attributes. For example, the input-checking strategy applies to several assurance subattributes, such as invalid data checking for reliability and unauthorized-access checking for security. Input checking also reinforces interoperability through validity and access checlung across system interfaces. It reinforces usability by providing rapid feedback on invalid user inputs. O n the other hand, the input-checking activi- ties requirc additional code, inernory, and execution cycles, and thus may conflict with the cost/schedule and performance attributes.

approach requires a domain- dependent knowledge base covering very detailed-level conflicts (such as conflicts of loan period in a library’s ten1 requirements). In con- trast, our approach focuses on domairi-independent conflicts involving high-level quality-attribute and arclii- tecture-strategy conflicts to achieve generality and scalability. A related and widely used approach for reconciling quality attributes is qual- ityfunctioii deploymeiit.’ ’ It is a largely manual approach for which QARCC can provide coinpleinentary auto- inateti support.

REFERENCES 1 . 1%. H~~elinn, “Some Steps TOM ard

F(irnial and :\titoinad Aid\ tu Sofm are Iieqniremcnts Analysis

Elaboration o f attribute architecture strategies. We are developing a foriiial s t ruc ture for t h e quali ty-attr ibute architecture strategies summarized iii

Table 2. It is currently composed of a dejinztzon for each elementary strategy, precondztzonr to check whether or riot the environment5 or situations are d i - gible for applying the strategies, po\f- cmzditzons to describe the results o r actions after applying the strategies, effect\ on quality attributes with ratio- nale, and optzoizc for resolving quality- attribute conflicts.

Figure 6 shows the struchire of ele- men tary arc hi t e c t u r e s t r a t e gi e s ib r quality attributes; Figure 7 shows three examples. T h e p~*e~07idztzons for the input-acceptability-check strategy ,ire sets of candidate inputs and acceptatill- ity c r i t e r ~ ~ ~ As the figure shows, the efecr on assurance is positive, while 1 he effects on performance, cost, schedule,

and Design,” Pmc. 11:11’ 74. Sdi Hollmd, Atnsterdam, 1974, pp, 192-197.

General Electric Commantl and Information System, S u n n y a l e , Calif., 1977.

3 . L). Schaus, “-\sGstant for Specify ing Quality Softuwe (:\SUS) Mission Analysis,” k\D(:-TR- 90-348, Rome Laboratory, 1ioIIle, N.Y., Tiec. iom.

1088.

5. S. Easterhi-ook. “IIandIing Con- f l ict Renvcen Uiimain Ueucrip- tioni with Coiinl~tit~r-Stt~~~”,ned Ncptiation,” K7iumleilge Acqiisi- tion, Mar. 1991, pp. 2S5-289.

6. L. Chung, U . Nixin, and E. Yu, “Lsing Son-I~unctional Require-

Rcquiremeiits big., T Press, T,o\ -\lannit(iu, C;alif., 1 9Oj,



Attribute

Assurance

Product Strategies

Accuracy optimization, backup/recover); diagnostics, error-reducing user inputloutput fault-tolerance functions, input checking, instrumentation, integrity functions, intrusion detection and handling, layering, modularity, monitoring and control, redundancy.

Iiiteroperabilitj

Usability

Performance

Evolvat)ility/ Portability

CosdSchedule

Reusability

All of Above

Distributability, generalitv, integrin functions, interface specification, lavering, inodulariq , self-containedness

Distributability (groupm are), error-reducing user inputloutput, help/explanation, modularin, navigation, U1 consistency, U1 tlexlbiliq, undo, user-programniabili~~, user-tailoring

,4rchitechiie balance, descoping, distributabilig , domain archltecture-dri.i.en, faster hardv are, instrumentation, optiinization (code/algorithm), parallelism, pipeliiiing, platform-feature exploitation

Distributability, generdlitv, input assertlodope clieclung, layering, modularin,, self-containedness, understandability, user-programmability, user- tailorability, verifiability, \ isibility functions.

Architecture balance, descoplng, domain architecture-driven, modulaiity, reuse

~

Domain architecture-drn en, portabilig functioni.

~~

Descoping, domain architecture-driven, reuse (if strong nit11 regard to attribute)

aiid evolvability are negative. W e followed six steps for building

thc knowledge base for tlie sti-ategy- attribute relations and quality-attribute strategies:

1. Identify primitive qmlity-attribute strategies. 'Table 1 summarizes the cui-- rent working set of strategies.

2. For each identified strategy, analyze the effects on each of tlie other primary quality attriliutes as positive (+) or negative (-). For any pair of strategies with tlie same + and - pattern, combine them if they are sufficiently synonyn1ous.

Process Strategies

Failure modes and effects aiialy analysis, formal specificati inspections, penetrauon, regres requireinents/design verificatlo

~~~ ~~

stress testing, test plans and tools.

~~~ ~~

Interface change control, interfa interface testing and analysis, in imoh ement, specification verifi

Prototping, usage monitoring a ~~~

user engineering, user-interface tools, user involvement

~~~ ~~~ ~

Benchmarhng, modeling, performance a protomping, simulation, tuning, user involvemeii

Benchmarhng, maintainer and user invol portability-evolution-vector specification, prototyping, requirement-evolution-vector specification and verification.

Design to costlschedule, early error-elim tools and techniques, personnel/inanageinent, process automanon, reuse-oriented processes, user and customer involvement.

Domain architecturing, reuser iiivolvemcnt, reuse-evolution-vector specification aiid 'i erification.

~ ~~~~ ~~~ ~~

Aulalvsis, continuous process improvement, iiicentix iLation, inspections, personnel/ management focus, planning focus, requirements/ design validation and verification, review emphases, tool focus, total quality niaiiagemeiit

3. Define the pi-rcoiidztioiis coizditioiis invoked in applving _ _ . d

ityattrihute strategies. These sharpen the strategy definitions, help validate the + a i d - assignments, and help ideii- ti@ inore complex interactions.

4. Elabora te t h e m o r e complex strategy-attribute relations (not just positive/ negative). For example, the mon i to r ing and cont ro l s t ra tegy improves assurance at the cost of iiear- term performance, hu t also collects performance data supporting long-term performance improvement via tuning.

5. Formulate options to resolve the

and post- the qual-

ident i f ied conflicts a m o n g qual i ty attributes. Performance tuning is one exaruple.

rience. 6. Update strategies based on expe-

QARCC OVERVIEW

Figure 8 shows the QARCC concept of operation for identifying potential quality-attribute conflicts, flagging thein for affected stakeholders, and sug- gesting options to resolve the conflicts.

QARCC is triggered by a staltehold-

M A R C H 1996


Primary Architecture Attribute Strategy

Asurance Input checlung

Redundancy

Backup/recovery

Monitoring and control

~

Inter- Input checking operability

Evolvabil ity /portability Layering

Modularity (platforin- dependent functions)

OtherAttribute OtherAttribute Special Cases/ Reinforcement Conflicts Comments

Interoperabillty, usability Cosdschedule performance

CostYschedule, evolvability, performance, usability

Cosdschedule, evolvability performance

Cosdschedule, Long-tcrm performance performance enforcement via tuning

~~ ~ ~~ ~ ~~ ~~ ~~

~~~ ~~~ ~~ ~~~ ~ ~~~~~ ~~ ~

Assurance, usability Cosdschedule, performance

In teroperability, Cost/schedule, performance reusability

Reusability, usability Cosdschedule, performance ~~~ ~ ~~~~ ~ ~~

(displays)

< d e f i n i t i o n > = [ < d i a g r a r n > ] D e L i n L t ~ on <string>

[ Pros <st r i n g > ]

P o r t a b i l i t y 1 Coit h S c h e d u l e 1 R e u s a b i l i t y .

Figzcve 6. The . s t i u C t u w ojelementaiy archztectuw strutegzes jbv qunlzty attt~zbutes.

er entering a new win condition with a quality-attribute taxonomy element. Figure 9 shows screendurnps f rom QARCC-1. For the attribute of portability in screen A, QAKCC first consid- ers its product and process stratcgies as given in Table I (such as layering to achieve portability). It then examines these strategies to search for potential conflicts with other attributes.

QARCC: determines these potential conflicts from the portion of its knowledge base suininarized in Table 2. For example, layering produces likely conflicts with cost/schedule a i d performance. (In QARCC-1, cost and schedule wcre combined under “developmcnt affordability” and performance was


called “efficiency.”) ’These are shown in the “potential conflict list” in screen B of Figure 9.

QARCC then uses the relationships shown in Figure -5 to identify the stakeholders affected by these potential conflicts (developer and cmtoiiier for cost and schedule; user and customer for performance). Fo r these stakeholders, QARCC pops up the “conflict advisor note” window (screen €3) with the potential conflicts list generated by the new win condition. T h e list also enumerates any existing stakeholder win conditions that have conflicted attributes in their “taxonomy elements” slot. If no such win conditions exist, a “missing win coil- dition” message is shown. For example,

in screen B, development affordability has two existing win conditions - hohin-winc-5 and hohin-winc-9 - but assuraiice and usability have none.

T h e stakeholder can select affected win conditions with the mouse and then click on the create i .me button to have QARCC draft an issue schema shown in screen C. If 110 affected win conditions exist, the stakeholder can click on the Cxate WinC button to have QARCC draft a win-condition schema, shown in screen D.

An example of the draft material pro- duced by Q A R C C is shown in the Other’s Comments field of screen C, which cautions the stakeholders that affordability strategies such as reuse will


+Output

Invalid input+J Definition:

Preconditions:

Postconditions:

Effects on Quality attributes:

An architectural composition that precedes a function by an acceptability check of its inputs

Candidate inputs, acceptability criteria

If valid, pass input into the Function, otherwise, indicate "Invalid Input" and exit

* Assurance (+) filters out unacceptable inputs Performance ( - ) input-check requires resources

Cost, Schedule ( ) more to specify, develop, and verify Evolvability (- ) more to modify

Layer 111 [AI

J i '+ Layer 11 \ / Layer I

Definition:

Preconditions:

Postconditions:

Effects on Quality attributes:

A hierarchical architectural composition in which each layer can communicate only with the adlacent upwards or downwards layer

Interface and protocol between a layer and an adlacent layer, request to pass data and/or control from layer to layer

Data and/or control passed from layer to layer, or notification of interface/protocol violation

Evolvability, Interoperability, Portability) Reusability (+) hides sources of variation inside interface layers Performance ( - ) requires more interfaces and data and/or control transfers via protocol

* Cost, Schedule ( ) more to specify, develop, and verify, can reduce integration cost and schedule

[BI Input -

onitoring - Performance analysls Definition:

the function (for example, to avoid buffer overflows), and/or reports the result for subsequent performance analysis Preconditions:

Postconditions:

Effects on Quality attributes: Assurance (+) avoids undesirable states Performance ( ) requires additional processing in short term, (+) improves performonce in long term via system tuning Cost, Schedule ( - ) more to specify, develop, and verify

[Cl

An architectural composition that monitors the performance of function, controls the configuration or environment to stabilize

Monitoring instrumentation, control limits and algorithms

If the function is stable, checks the performance and reports it, otherwise stabilizes the function by controlling the configuration or environment

7 Figure 7. T h r e e exawple.7 o f p ~ z m z t z v e giinlityattidmte n i zh i t e r t i i~~ l stmtegzes. (A) znput-acceptahlzty check, (B) layemzg, a n d (C) ???oYImT?zg

coiiflict with the portability win condition i f the reused software is n o t portable.

For each attribute strategy identified,

negative effects on other attributes

akeholders enter win By clicking the Optzom button at die - determine likely bottom of screen C, the stakeholder can have QARCC draft a set of candidate resolution optioiis. As the left window

Figure 8. QARCC concept o f opemtion.

in screen E Shows, the QARCC knowledge base generated six opt ions to resolve the conflict between development affordability and portability:

+ reduce or defer product hnctions; + find, incorporate some relevant

+ find, engage expert performers; + use design-to-cost process and

identify lower priority features to defer if necessary;

+ relax constraints on schedule,

reusable software;

M A R C H 1996


Win-Condition 7

~~

N-,"le &c.,rr Wakeholder

'1'0 : Developer, Customer. User. Maiatainer. intemperntor S t h j d Pot.,,fial curxflist h m m l,d,i,,-,,~"~-li

The t iex, win condition ( hahin-winc-ll ) ~ EntercdIxy. hohin (User ) -On Attribute : Portability

resitlk in the following potential conflicts.

...............

\ /1 Conf lict/Ris k/Un certa in ty \

!?!%:: ............

i COCO..," I Cnnccl I

Figwe 9. An exumple of the izztznl zmplementatzoz of'QARCC.



Found, Not found Found, by QARCC significant insignificant

Conflicts found in WinWin user exercise 0

Conflicts not found in WinWin user exercise 0

per formance , hardware, and o the r attributes; or

+ use better tools and practices. As t h e opt ions a re genera l ized ,

stakeholders can tailor them to their special situations. QARCC also drafts pros and cons for the options (right window in screen E), he lp ing t h e stakeholders evaluate the options and converge on ;I mutually satisf,actory (win-win) option.

EXPERIMENTAL RESULTS

QARCC-I has been applied to several sample projects, primarily in satellite ground stations. I n the experiment described here, we applied QARCC retroactively to the win conditions for a representative SEE to support a satellite- ground-station product line. T h e representative developer was a workstation vendor’s CASE division, die representative user was a large aerospace ground- systems division, and the representative customer was the hypothetical US Space Systems and Operations Command.

T h e mu 1 ti stake 11 o 1 de I- W i n Wi n exercise generated 2 1 win conditions, including the following quality-related conditions:

+ Ini t ia l opera t iona l capabili ty (IOC) cost less than $7 million

+ Full 1OC delivery schedule with- in 25 months

+ Interoperable SEE functions and tools

+ Low development risk + Low maintenance cost; easy to

2 0

> 3

111 odi fy + C om in er ci a li za b 1 e in i d d 1 ex7 ar e

and commercially supported SEE to improve evolvability

+ Broadly applicable across product line to improve eYoi.\-ability

T h e main objective of the 14‘inJVin exercise was to determine the ability of TVinT4’in to support renegotiation of a new win - i n e q u i 1 i b r i u m so lu t ion when a new win condition was added to the base of 2 1 in-equilibrium win conditions. T h e new win condition, “support the development of multi- mission satell i te ground s ta t ions,” caused a cost and schedule conflict with the previousll- negotiated equilibrium. After determining that VhTVin could successfull!- support such a rene- go t ia t ion , ’ we dec ided to apply QARCC to the body of win conditions to see how- many potential conflicts it would identify.

First, we wanted to see if QARCC would identi+ the two conflicts used in the renegotiation process. These Tr-ere conflicts of cost/schedule with evolvability and interoperability: T h e stake- ho lders had re jec ted a n op t ion t o recover cost and schedule by reusing legacy software that was deficient in evo lva b i 1 i ty an d in t e r o p e r a b i li ty . Second, we wanted to see if QARCC would identify o ther potential conflicts, and if so, how many of thein would have significant rele\-ance to the satellite-ground-station system.

T h e results are shown in Table 3. QARCC found the two significant conflicts identified in the VC’inWTn

exercise. It also found e ight niore potential conflicts. Five of these were considered significant in the satellite- ground-station situation: conflicts of cost/schedule with assurance, performance, and reusability; and conflicts of interoperability and evolvability with performance. The conflicts not considered significant were those of evolvability with assurance and usability, and a conflict of cost/schedule with usability. W e are reviewing these three “false alarm” situations to determine if the potential-conflict threshold for them was set too low for other situations as well. If so, we plan to drop them as being more time-consuming than beneficial.

rom our initial experimentation, we concluded that QARCC can

rt users, developers, customers, and other stakeholders to conflicts among their software-quality requirements and can help them identify additional, potentially important quality requirements . W e also concluded t h a t QARCC needs further refinement to avoid overloading users with insignificant quality-conflict suggestions. W e are now refining the knowledge base to address more detailed quality attributes in a more selective fashion.

In our discussions with USC-CSE’s industry and government affiliates who p a r t i ci p a t e d i n d e m o ns t r a t i o n s of QARCC-1, there was a strong coiiseii- sus that it provided a useful framework fo r s takeholders t o systematically resolve software quality-attribute conflicts. They also agreed that the semi- automated approach provided a good way to balance human skills and coin- puter tools in addressing quality-trade- off issues.

In our development and experimentation with QmCC-2, we are hoping to show that the QAxCC approach is also scalable t o large systems wi th many quality conflicts and that the effectiveness of the QARCC approa is largely domain-independent.

M A R C H 1996


ACKNOWLEDGMENTS This research is sponsored by the Advanced Research Projects Agency through lloine 1~ahol.atory under contract F30602-94-C-0195 aiid hy the

eiiter fur Software Engineering: rierospace urce Cost Analysis Agency, A T & T Bell Laboratories,

Bellcore, G ~ m ~ i u t c r Science Corporati~n, Defense Information Systems Agency, E-Systems/RaytIic~,n, Electronic Data Systems, H ~ i g l i c ~ Aircraft, Institute for lIefcn\c fhalysis, Interactive Dcvclopinent Envii-onments, Jet Propulsion Lalxnitory, 1,itton Data Systems, I,ockheed/&lartin, Lord Federal Sy\tcmc, MC<: Inc., Motorola, Northrop Gmminan Corporation, Rational Siiftware, Rockwell Intermational, Science Applications International, Suftw are Engineering Institute, Software Productivity Consortium, Sun h~ici-o\y\tcnh, ’l‘exas Iiistrunicnt~, -TKRT Inc., us Air Force Rome Laliimitory, us k i n y Research Labm‘atory, and Xerox Corporation.

REFERENCES 1. B. Bochin et ai., “Softvare kquircments hs Kegotiatcd M’in

(:oiiditions,” I’/YJc. Firv lizt’l Conf Kequiremena E n g , IEEE CS Press, Lo5 Alatni~os, Calif., 1994, pp. 74-83.

2 . B. noehm et al., “Software Requirements Negotiation and Renegotiatloii Based Spiral Approach,” Proc. 17th lnt’l CO?$ Snfmxwe ss, Los hlamitos. Calif., 1995, pp. 243-253.

3 . R. R i d i m . and K. Koss, “Theory W Software Project ,Managcmcnt: I’ri tici p I cs and Examples,” 9 16.

4. V. R‘isil i and 11. Koinhach, “Tailoring the Software Process to Project (;oak and Eiivironinent~,” P m . 9th ht’l Cui$ Sujhuare Eqq., IEEE CS

Tu/L. St$wnrc Eng.,JuIy 1989, pp. 902-

Software ’l‘ech. Report TRIV-SS-73-00, ’1‘1IW Systcins and Energy, Inc., Redondo Bench, Calif., 1973.

6. J. M c C d I , P. llichards, and G. R’dters, “Factors in Software yuality,” Tech. Report 77ClS02, Ceneral Electric Command & Inforination Systems, Suiiiiyvale, Calif., 1977.

Barry Boehm is the ’I‘KLL’ Professor of Software Engineering and Director of the Center for Engineering a t the UniLersity of Southcii ( His curreiit research involves the WinWin group=-are system for software requirciiiciirs negotiation, architcc- ture-based ni(idels of software quality attributes, and the Cocoino 2.0 cost-estimation model.

University and an lVIS and PhD in mathematics froin Roehin received a BA in inatlieinatics from Hamiard

Hoh In is a PhD strident at the Center for Software hgineering at USC. His research interebtb are in quality coiiflict resolution, including knonledge-based soft- \\ are reqtiireineiits engineering, software architecture, design patterns, and software inetrics aiid cost-estiiiia- tiun inodcls.

Hoh rcceivcd a US and an MS i n computer science from Korea University and won prizes for papers from the Korcaii Information Society and the Korean Academy Promotion Foundation.

Address questions about this article to Boehm or In a t the Ceiiter for Software Engineering, US(:, Los r\ngeies, Calif. 90089-078 1; [email protected] or [email protected]. Additional information is available a t http://suiiset.usc.edu.


CALL FOR PAPERS

& Third IEEE International Symposium on

Requirements Engineering January 5-8, 1997 Annapolis, Maryland, USA

The 1997 symposium will be held in four exquisite 18th-century inns clustered in the beautiful colonial scaport of Annapolis on the scenic shores of Chesapeake Bay. It will bring together researchers and practitioners for an exchange of ideas and experiences. The program will consist of invited talks, paper presentations, panels, tutorials, working groups, demonstrations, and a doctoral consortium. The program will also includc a parallel industrial track with presentations on industry problcins and experiences, transferable technology, and commercial tools.

Papers describing original research in requirements cnginccrinj; arc invited. Symposium organizers extend a special invitation for paper submission and participation to rcscarchcrs and practitioners working in high assurance, safety-critical and mission- critical systems, and formal approaches to requircmcnts.

Authors should submit six ( 6 ) copies of each full paper (no cmail or FAX) to the Program Chair. Papers must not cxcced 6000 words and must be accompanied by full contact infonna- tion including name, address, cmail address, and telephone and FAX numbers. Authors should also submit the title, abstract, and classifications of each paper by email to the Program Chair a month before the paper is due along with full contact information. All papers must be classified according to the symposium classification scheme. For a full call for papers, including the classification scheme, contact the Program Chair, use anonymous FTP from cs.toronto.edu (/distfISRE97/CFP), or sec the WWW page at http://www.itd.nrl.navy,mil/conf/ISRE97. Developers or researchers wishing to present in the industrial track should submit an abstract to the Industrial Chair. Students intcrcskd in presenting at the doctoral consortium should send an extended abstract to the Doctoral Consortium Chair by Sept. 15, 1996.

IMPORTANT DATES: April 1, 1996: Title, abstract, and classifications due May 1, 1996: Full papers, industry abstracts due July 1, 1996: Notification of acceptance September 1, 1996: Camera-ready copy due

FOR MORE INFORMATION, CONTACT: Connie Heitmeyer, General Chair

John Mylopoulos, Program Chair

Code 5546, Naval Research Lab, Wash., DC 20375 +I-202-767-3596; [email protected]

Dept. Computer Sci., Univ. of Toronto, 6 King’s College Rd., Rm 283, Toronto, Ontario Canada M5S 3H5 +1-416-976-5180; fax +1-416-978-1455 jm Qcs.toronto.edu

Stuart Faulk, Industrial Chair Kaman Sciences; +I -202-404-6292 faulkQ itd.nrl.navy.mil

Myla Archer, Doctoral Consortium Chair Naval Research Lab; +1-202-404-6304 archerQitd.nrl.navy.mil

Sponsored by

C ~ ~ P U T E R SOCIETY 5 0 Y E A R S OFSERVICE - 1 9 4 6 - 1 9 9 6

IEEE Computer Society TC on Software Engineering In cooperation with

ACM SIGSOFT, IFlP WG 2.9 (Software Requirements)


mailto:[email protected]


http://suiiset.usc.edu

http://cs.toronto.edu

http://www.itd.nrl.navy,mil/conf/ISRE97


http://Qcs.toronto.edu

http://itd.nrl.navy.mil

http://archerQitd.nrl.navy.mil

identifying quality requirement conflicts …ece473/readings/27-identifying quality.pdf ·...

Documents