From: AAAI Technical Report WS-93-07. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Collaborative design in system development:
Whatplace for design rationale?
L. Candy and E. Edmonds
LUTCHIResearch Centre
Deparrtment of ComputerStudies
Loughborough Leicestershire LEll 3TU
United Kingdom
1. Introduction
This paperreports a study of the use of DesignRationalemethodsin the co-operativedesign of
a software system. Structured records of the design process aim to support the understandingof
decisionstaken and therebyallowdesigners to give better informedreconsiderationto themat a
later stage. This can be particularly importantduring maintenance.Methodsfor capturingthe
complexityof design deliberations in order to producea DesignRationale (DR)in software
design are still in the early stages of research (Carroll & Moran,1991). Theapproachesadopted
are diverse: for example,fromconstructing representationsfor DRthat are applied by the
designeras part of the reflective process(e.g. MacLean
et ai, 1991)to relating DRto design
practice by examiningconcrete problemsrather than abstract issues (e.g Lewis, Riemanand
Bell, 1991). Nevertheless,evidencedrawnfromactual data gathered about the process of
softwaredesignin practice remainslimited.
2. Design of a Software Artifact
A softwaresystemcan be viewedas an ’artifacf that embodiesimplicit theoretical constructs
that realize functional and operational requirements(Carroll and Campbell,1989). Throughout
the designprocess, structures are chosenbecauseof their ability to achievethe intended
functionality, and such decisionsmaybe evaluatedagainst various criteria. Duringthe design
processthe descriptionsare modifiedand there is a clarification and refinementof intended
functions and requirements.Theremaybe additional factors arising fromthe context of the
project that affect the waythe processis carried out : for example,the needto keepsight of the
general applicability of the design whilst meetingdomainspecific needsin a bespokeapplication
or the constraints of the givenhardwareplatformand the softwarearchitecture and tools. In
particular, it is necessaryto be awareof the influenceof the differing contributionsof the team
membersarising from the application of experienceand skills to the common
problem
addressed.
3. A Study of Collaborative Design
This paper drawsuponan exercise in collaborative design of a Knowledge
SupportSystem
(KSS)(Edmonds
and Candy,1993) in whichan attempt wasmadeto elicit design rationale
during the designprocessitself. It describesthe evolutionof the systemdesign as it emerged
fromthe initial requirementsdocumentto the design specification of the newsystem. The
283
collaborative design process described concentrates uponthe designer/programmers,
primarily,
but also takes accountof the roles of the other members
of the team, suchas the user and the
independentev’,duator.
Thedesign process wasdocumented
from the conceptual phase to the implementationof the
first prototypeconstructedin the intendeddelivery vehicle. Morerigorous proceduresthan used
in an earlier version of the systemwereemployedand methodsfor recording the development
processin all areas of the project activities discussed.It shouldbe notedthat this wasa major
re-designexercise building uponthe evaluationresults froman earlier system(Candyet al,
1993). Thusan explicit attemptto incorporateDRduring the process of interpreting
requirementsinto design wasmade.Theinitial primarygoal of building DRinto the design
process of the re-design of the systemwasbased uponthe hypothesis that this wouldimprove
the designresults by eliciting decisionsbaseduponjustifiable criteria, enablingthe sharingof
design thinking and encouragingmore’rigorous’ attention to usability issues (as defined for
examplein TheGuideto Usability, 1990and Smithand Mosier, 1986). Validation procedures
wereapplied at all stages of the design activities havingbeendevisedand agreedby the team.
Theseproceduresrequired the designers to justify options and decisions during the process and
that designguidelines fromresearch literature wouldbe applied whereappropriate.
Requirementswere to be based uponthe evidencefrom previous studies. Solutions and
possible options available to meetrequirementswouldbe identified and documented.Theidea
of a design databasefor this purposearose fromthe discussionsthat took place. Designchoices
and decisions wererecordedand a detailed accountof howa solution wasto be handledgiven.
In the conceptualdesign phase, the requirementswereinterpreted by the teamas set of design
options. Theseoptions werethen validated against the requirementsstatementsby the user and
the evaluator. Therequirementsdocumentand the design drawings, notes, documentsand
prototypes(dynamicsimulations) represented the shared understandingof the team and as such,
providetangible records of the evolution of the decision making.Themonitoringof their use
providedevidenceabouthowdesign of this kind actually takes place in situations constrained
by time and resource limitations. Thesefactors whichemergedabout the dynamicsof the’group
thinkingare identified. Twomaintasks carried out by the designersare highlighted:firstly, the
joint interpretation of initial generalrequirementsand, secondly,the selectionand use of the
materialsand tools of design.
4. Conclusions
Thedesignrationale ideas that informedthe initial intentions of this exercise werebasedupona
modelof design that is rational, deductiveand hence, can be shared. Theevidencefromputting
this into practice is that the designprocessesare disruptedby the requiredanalytic
considerations and that the process is strongly synthetic, based uponmodelsof knownsystems
and the handlingof newsystems, during construction. Therationale that did emergeis post
hoe, and, in effect, a rationalisation of designdecisionsrather than a true accountof the
unfoldingof the process. Theobservationof the design processand its outcomesled us to
concludethat DRas applied in the formused, did not necessarily support the co-operative
designprocessitself. Theseresults suggestthat it is difficult to applyDRas a supportto the
design process whilst nevertheless being able to providean analysis of whathappened.DRas
something
opento scientific scrutiny as a psychologicalor sociologicalarea of study is
possible. However,
the ingredientsof designpractice itself are not necessarilysubject to the
samekind of analysis. Questionsare posedas to the kind of knowledge
that is required for the
support of co-operativesoftware design in practice. Thus, whilst DesignRationalemightbe
valuable as a post hoe methodfor communicating
betweendifferent stages of the design,
developmentand maintenanceof process, other methodsare required to facilitate
communication
and sharing during a given design phase.
284
5. References
Carroll, J. M.and Campbell,R.L.(1989).Artifacts as psychologicaltheories: the case
human-computer
interaction. Behaviourand Information Technology,Vol.8, No.4, pp 247256.
Carroll, J.M. and Moran,T.P. (1991) Introduction to this special issue on design rationale.
Human-ComputerInteraction,
Volume 6, Nos 3 & 4, pp. 197-200. Lawrence Erlbaum
AssociatesInc.
Lewis, C., Rieman, J. and Bell B. (1991) Problem-centred design for expressiveness and
facility in a graphical programmingsystem. Human-Computer
Interaction, Volume6, Nos 3 &
4, pp.319-355. LawrenceErlbaumAssociates Inc.
MacLean,A., Young,R.M., Bellotti, V. and Moran, T.P. (1991) Questions, options, and
criteria: elements of design space analysis. Human-Computer
Interaction, Volume6, Nos 3 &
4, pp.319-355. LawrenceErlbaumAssociates Inc.
Maclaren, R., Hornby,P., Robson,J., O’Brien, P., Clegg, C. and & Richardson, S.System
design methods- the humandimension (1991) Project IED/4/1249Report. DTI/HMSO.
J., Benyon,D., Davies, G., Keller, L. and Rogers Y. (1990) A Guide to Usability.
The OpenUniversity in association with the Departmentof Tradeand lndustry.
Preece,
Smith, S.L and Mosier, J.N. (1986). Guidelines for designing user interface software, Mitre
Report 10090 ESD-TR-86-278,Bedford Massachusetts, August.
285