A Tool to Support Collaborative Software Requirements Management

A Tool to Support Collaborative Software RequirementsManagement

Michael Lang1Michael Lang1 and Jim Duggan2and Jim Duggan2

1Department of Accountancy and Finance, National University of Ireland, Galway, Ireland; 2Department of Information Technology, National University ofIreland, Galway, Ireland

The system requirements specification (SRS) is a highly

dynamic document that grows and evolves throughout asoftware development project, and it is critical that it be

carefully engineered and managed. Because the SRS

fulfils many roles and is of interest to a diversity of

stakeholders, its management should be a collaborative

process supported by an automated tool. Commercial

requirements management tools are at present insuffi-

ciently versatile to support collaboration between a

multidisciplinary and potentially distributed team ofstakeholders. The requirements for such a collaborative

tool are herein presented, alongside the design of a

prototype and the findings of its application in a case

study.

Keywords: Computer-aided software engineering;Requirements management; Requirements volatility;Software development process

1. Introduction

Software development is not merely a technologicalchallenge, but is also a complex social process, andis arguably the most intensive of all engineeringdisciplines as regards human communications. Effectivecommunication amongst the stakeholders of a softwaredevelopment project is vital to its success. Conversely,if communication is ineffective, the likelihood ofdelivering a successful system is remote.

In particular, the communication of softwarerequirements is extremely problematic. Often, much of

post-delivery maintenance work can be traced torequirements which had been poorly or falsely describedin the system requirements specification (SRS), or weremissed altogether. Significant productivity gains stand tobe realised if communication can be improved. In orderto bring about improvement, an effective process and theinfrastructure to support it must be provided.

This paper is founded on the proposition that thesoftware requirements management process must neces-sarily be a collaborative activity because of thecomplexity of communication involved. We argue thatpresently available requirements management tools areinadequate to support all aspects of such a collaborativeprocess. In view of the shortcomings of commercialtools, a prototype was designed and constructed by theauthors, and validated in a case study. This prototype,hereafter referred to as RM-Tool, seeks to manage andcontrol requirements within a process that activelyengages multidisciplinary, distributed project teams. Itis based upon a multi-user Web-enabled multimediadatabase, implemented using Lotus Notes groupware.

2. Research Method

Drawing from the literature in the areas of requirementsmanagement, communications theory and cooperativework systems, the authors derived a core set ofrequirements that a tool for collaborative softwarerequirements management must address. These require-ments were classified as ‘mandatory’ ‘desirable’, or‘optional’, and were allocated priorities (see Fig. 1).

The next step was then to assess the extent to whichcurrently available requirements management tools fulfilthese requirements. There are so many commerciallyavailable tools that claim to support the requirements

Requirements Eng (2001) 6:161–172� 2001 Springer-Verlag London Limited Requirements

Engineering

Correspondence and offprint requests to: M. Lang, Department ofAccountancy and Finance, Galway, Ireland. Email: [email protected]

management process (or part of it) that it was neitherreasonable nor possible to perform a detailed assessmentof them all. The authors therefore adopted an evaluationmethodology with the objective of reducing thisextensive set of tools to a select few ‘best in class’products. Tools that did not meet mandatory require-ments were automatically eliminated. The remainderthen underwent closer inspection, based on the match ofproduct features to prioritised requirements. From thisassessment, a shortlist of nine tools was compiled, eachof which were subjected to detailed evaluation. Theseevaluations revealed a number of prevalent weaknesses,which in turn became the motivation for the design ofRM-Tool. To validate RM-Tool, it was applied in a casestudy, for which findings and analysis are presented. Amixture of qualitative and quantitative techniques wasused for collecting case study data.

3. Background to the Study

3.1. Aspects of Human Communication

There is general agreement on the components of amodel of human communication [1]. A key factor in theeffectiveness of communication is the similarity betweenthe environments of the sender and the receiver of amessage – that is, the closeness of their respectivebackgrounds and cumulative experience. Individualswith different environments perceive things differently,and this is a principal cause of misunderstandings. InFig. 2, the ovals denote the scope of the environments ofthe sender and the receiver. The overlap between theseenvironments signifies shared knowledge and experience– the greater this overlap, the more effective thecommunication.

The effective communication of software require-ments is a formidable challenge. In the first instance, theconceptual structures of software systems are arbitrary,complex, difficult to visualise and difficult to describe[2]. Secondly, software requirements managementnecessitates ongoing communication between stake-holders from a diversity of disciplinary backgrounds,all with different levels of expertise, interests andobjectives [2–4]. This greatly increases communica-tional overheads, and raises a need to use a variety ofcomplementary techniques to specify requirements.Thirdly, it is typically the case in requirements definitionthat, at the outset of a project, the end-user has an expertunderstanding of the operational context, and thedeveloper has a well-informed grasp of technology, buteach may be a comparative novice in the environment ofthe other [5]. Communication in software developmentmust therefore be an ongoing process, whereby users,developers and other stakeholders continually exchangeknowledge, thereby altering perceptions, shifting ex-pectations and eradicating false assumptions [6].

3.2. Communicability of the SRS

The objectives of the software requirements manage-ment process are to develop a shared, documentedunderstanding of the requirements (in the form of theSRS), and to enforce a mechanism to control volatility sothat the system satisfactorily fulfils requirements at thetime of its delivery [2]. In order to induce quality indevelopment, there must be quality in requirementsmanagement.

Inadequacies in the SRS can have a crippling effect. Itis vital that requirements be carefully managed on anongoing basis. Individually, requirements should beconcise, design-independent, feasible, precise, complete,consistent and verifiable. As a whole, a set of

Fig. 1. Research method.

Fig. 2. Model of interactive human communication.

162 M.Langand J. Duggan

requirements should be complete, prioritised, organised

in a clear structure, traceable and maintainable [2,7,8].

Above all, requirements must be communicable. This

has two aspects: firstly, that a requirement should be

unambiguous; and secondly, that it should be under-

standable. Communicability is a presupposition of some

of the other characteristics of requirements; for example,

completeness and feasibility cannot be assessed if a

requirement is not communicable.

A requirement is said to be unambiguous if it has only

one possible interpretation [7,8]. If a requirement is open

to conflicting interpretations, there may be disagreement

on what exactly is to be delivered [2]. Therefore, the

specification techniques used must not leave a doubt in

the reader’s mind as to the intended meaning [8].

A requirement is understandable if all its readers can

easily comprehend its intended meaning with a

minimum of explanation. The specification of under-

standable requirements is entirely the obligation of the

writer; it should not be incumbent upon the reader to

educate himself in a foreign language [7].

The SRS has two primary audiences: the client

organisation, and the technical community. Both these

audiences comprise a variety of interested subgroups.

This has a profound impact on communicability issues,

because it raises a need to employ a variety of different

notations, languages and other specification techniques

in conjunction with each other within or alongside the

SRS.

There are hundreds of requirement specification

techniques in common use throughout Europe [3]. Of

these, natural language descriptions is the only technique

that is generally understandable by all potential users of

the SRS, and for that reason alone should always be used

[9]. However, the shortcomings of natural language as a

specification technique are well recognised, most

notably its susceptibility to ambiguity and inconsistency

[9,10]. Replacing natural language with more structured

notations greatly decreases ambiguity, but almost always

at the expense of understandability. Therefore, natural

language should always be augmented by other

specification techniques [7]. Diagrammatic modelling

techniques are a popular approach amongst developers.

However, end-users are disadvantaged when asked to

validate such diagrams, as it typically requires them to

translate their knowledge into an unfamiliar language

[6]. Therefore, modelling techniques may be insufficient,

or even useless, in communicating with users. Often, a

better approach is the use of prototypes, which have been

found to be extremely beneficial as a communicational

aid between developers and users because they combat

the ‘invisibility factor’ [17].

3.3. Collaborative Systems Development

The importance of user involvement has been seen to bea very significant factor in overall project success.However, experiences indicate that merely involvingend-users does not guarantee anything – indeed, userinvolvement has been observed to have negligible oreven negative impacts [11]. The issue is therefore not ifusers should be involved in systems development, butrather how they should properly be involved. It isgenerally accepted that users should not becomeinvolved in technical design. Rather, the human–computer interaction (HCI) community advocates twopotential roles for users:

1. to enable the developers to acquire a detailedunderstanding of users’ work;

2. to verify that proposed solutions satisfactorily meetusers’ needs.

Traditionally, working relationships between users anddevelopers have been poor [10]. Users are disenchantedbecause developers consistently deliver unsatisfactorysystems; developers are disenchanted because they areallocated the entire blame for system failures. Further-more, users and developers have inconsistent objectives:developers want the SRS to be precise, specified infunctional terms, and finalised; whereas users expect theSRS to be flexible, open to interpretation, fully inclusiveof all their requests, and expandable on an ongoing basis.The formation of a multidisciplinary project team istherefore recommended to reconcile these divergentperspectives and to arrive at mutually agreeabledecisions [9,13,14].

For complex projects, it is necessary to integrateknowledge from many disciplines. Approaches thatemphasise the integration of upstream and downstreamactivities through the formation of multidisciplinaryteams, such as Rapid Application Development,Facilitated Application Specification Techniques andConcurrent Engineering, have become popular in recentyears. Multidisciplinary teams provide the benefits ofseveral viewpoints as stakeholders work together toidentify problems, propose solutions, and negotiatedifferent possibilities. With a dynamic, give-and-takeapproach, the team is empowered to make realisticdecisions that achieve the best, most workable outcomesfor all [11].

4. Assessment of Requirements ManagementTools

Most of the advances in software development tools andtechniques over the last three decades have focused on

ATool to Support Collaborative Software Requirements Management 163

productivity rather than quality, and have been primarilyconcerned with the work of individuals [13]. What isnow required is a means to boost the productivity andquality of work done by teams. Often, these teams aredispersed at geographically distributed sites.

Sales of requirements management tools have beengrowing steadily in recent years [15]. There are so manytools currently on the market that claim to support therequirements management process (or part of it) that it isneither reasonable nor possible to perform a detailedassessment of them all. In order to conduct a meaningfulassessment, it is necessary therefore to first identify thecore requirements of a tool for collaborative require-ments management, and then to evaluate the features ofcommercial requirements management tools againstthese requirements.

4.1. Requirements of a Tool for CollaborativeRequirements Management

The basic requirements of a requirements managementtool are well established in the literature [9,16]. Giventhe emphasis of this study on support for multi-disciplinary, distributed collaboration, some furtherrequirements are imposed. In summary, a tool to supportcollaborative software requirements management mustbe able to:

. maintain uniquely identifiable descriptions of allrequirements;

. classify requirements into logical user-defined group-ings;

. specify requirements using textual, graphical, andmodel-based descriptions, with support for rich mediadescriptions (such as images and animated simula-tions);

. define traceable associations between requirements;

. verify the assignments of user requirements totechnical design specifications;

. maintain an audit trail of changes; archive baselineversions; and engage a mechanism to authenticate andapprove change requests;

. support secure, concurrent cooperative work betweenmembers of a multidisciplinary team, which may begeographically distributed;

. support standard systems modelling techniques andnotations;

. maintain a comprehensive data dictionary of allproject components and requirements in a sharedrepository;

. generate predefined and ad hoc reports;

. generate documents that comply with standardindustrial templates, with support for presentation-quality output, WYSIWYG preview, and in-builtdocument quality controls;

. connect seamlessly with other tools and systems, bysupporting interoperable protocols and standards.

4.2. Weaknesses of Current RequirementsManagement Tools

In consideration of these requirements, the authorsconducted a review of vendor offerings. As describedearlier (see Section 2), a short-list of currently available‘best-in-class’ requirements management tools wascompiled, outlined in Table 1.

These tools were then evaluated in detail so as todetermine overall strengths and weaknesses. While mostof the short-listed tools fulfil all or nearly all of theaforementioned requirements with varying degrees ofcoverage, a number of prevalent weaknesses wereobserved, outlined as follows.

4.2.1. Usability and Comprehension Issues forNon-Technical Users

Some tools that are marketed as requirements manage-ment tools should properly be classified as systemsengineering/CASE tools. Such tools are specificallydesigned for use by skilled specialists who are proficientboth in software engineering methods and the function-ality of the tool itself. Because of the complexity ofCASE tools, and of the artefacts that they produce, theyare not practical for communicating with non-technicalstakeholders [14]. Indeed, it has been noted that CASEtools can at times even diminish the effectiveness ofcommunication between designers and end-users [17].Clearly, the orientation of CASE tools means that theyare by themselves inadequate to support a collaborativerequirements management process involving multidisci-plinary teams.

Table 1. Leading requirements management tools

Tool Version Vendor

CORE Enterprise 1.3 Vitech CorporationDOORS 4.0 Quality Systems & Software LtdCaliber-RM 1.0 Technology Builders, Inc.RDD-100 4.1.1 Ascent Logic CorporationRequisitePro 4.0 Rational Software CorporationicCONCEPT-RTM 3.7 Integrated ChipwareSLATE 4.1 TD Technologies, Inc.Vital-Link 2.3 Compliance Automation, Inc.XTie-RT 3.1 Teledyne Brown Engineering


4.2.2. Imbalanced Choice of SpecificationTechniques

It is recommended practice that requirements should bedescribed using both user-favoured methods (such asnatural language) and developer-favoured methods (suchas model diagrams) to enhance communication and toachieve a balance between technical clarity and generalunderstandability [9]. Few tools achieve this balance.Some are document-based with support for narratives,annotations and semi-structured natural language de-scriptions, but provide little or no modelling capabilities.Others, more akin to CASE tools, have strong modellingcapabilities but are restrictively rigorous, as they do notpermit natural language or other highly expressive mediasuch as rich pictures. Very few support compoundmultimedia documents.

4.2.3. Lack of Support for Collaborative Work

The orientation of quite a few tools is towards the stand-alone work of individual users, even though theimportance of technological support for coordinatedteamwork is widely accepted [13, 14]. Of those tools thatsupport collaborative work, none are ideally suited foruse by a multidisciplinary, distributed team where thestakeholders have diverse skills and needs.

Previous research has revealed that there is littleindustrial adoption and infusion of automated tools thatsupport coordinated, collaborative software development[18]. CASE repositories are a first step. However,purposeful collaboration requires a higher level ofgroup communication than merely accessing a sharedrepository. Rather, there must be continual interpersonalengagement so that shared understandings of complexissues emerge. Currently available tools do not offer asufficiently powerful collaboration mechanism to effec-tively achieve this.

5. Prototype Design

We see the aforementioned shortcomings as the mostsignificant impediments to effective collaborative re-quirements management. In an attempt to address theseshortcomings, a prototype, RM-Tool, was designed andconstructed. It is based upon a multi-user Web-enabledmultimedia database, implemented using Lotus Notesgroupware. As RM-Tool is a research prototype, itsscope is strictly limited. Rather than ambitiouslyattempting to provide full coverage for all therequirements earlier set forth, it concentrates primarilyon those that are presently ill satisfied by commercialtools.

5.1. Overview of RM-Tool Features

RM-Tool seeks to manage and control requirementswithin a process that actively engages multidisciplinary,distributed project teams. The key objectives of RM-

Tool are:

. to facilitate improved communication and under-standing of requirements amongst all project stake-holders by providing a balance between technical andnon-technical specification techniques;

. to facilitate enhanced collaboration between devel-opers and end-users during requirements definitionand verification;

. to engage a mechanism to control the impact ofchanges to requirements.

The first and second objectives correlate directly withthe observed weaknesses of current requirementsmanagement tools. The third objective is a corollary ofthe first two; given the added dynamism of acollaborative approach, the management of changes torequirements becomes all the more crucial.

Figure 3 provides a high-level overview of thefunctions of RM-Tool and the various roles played bythe stakeholders. Although the stakeholders havedifferent types and levels of involvement, note thatthere is no function that is of interest to only a singlestakeholder. RM-Tool was designed with this divergenceof viewpoints very clearly in mind.

The key features of RM-Tool are that it:

. maintains a shared data dictionary within a centra-lised, multi-user, multimedia database with full Web-based access;

. maintains requirement descriptions using both techni-cal and non-technical techniques, with hyperlinksbetween corresponding descriptions;

Fig. 3. High-level use case diagram for RM-Tool.


. provides basic support for standard modelling nota-tions;

. supports the storage and manipulation of rich text andcompound multimedia documents, which is especiallyuseful for describing complex requirements and fordemonstrating simulated implementations;

. supports time- and location-independent electroniccommunication between a team of stakeholders usingsecure, authenticated connections;

. supports backwards and forwards tracing of require-ments, from source through to implementation;

. facilitates project management, by allocating prio-rities, responsibilities and deadlines;

. has extensive reporting capabilities, and can generatea hard-copy SRS.

RM-Tool does not mandate or impose any formalisedmethodology or paradigm. Rather, it has componentsthat are capable of supporting process-centred, data-centred and/or object-oriented techniques (see Fig. 4).User Requirements are the focal documents in the

RM-Tool database, and are typically described usinguser-centred techniques such as natural language, usecase scenarios, mock-up sketches, and dialogue flow-charts. RM-Tool features a rich-text editor, and canadditionally import data in many standard word-processor, spreadsheet, and database formats, as wellas graphics, images, animations and other media types if

necessary. The requirements may be categorised into

logical, user-defined groupings to facilitate better

organisation and management. If necessary, it is possible

to derive lower-level requirements from higher-level

ones, and to specify correlations and dependencies

between requirements. For each requirement, its

source, method of capture, owners and authorised editors

are specified.

Once a user requirement has been input, the

development team can analyse it to define effort,

resource usage, technical feasibility and target imple-

mentation date. RM-Tool insists that end-users specify a

priority (‘Mandatory’ or ‘Optional’) for each require-

ment, and justify its benefit. Thus, the efforts of

developers can be prioritised and deployed where of

greatest advantage. Furthermore, RM-Tool aims to

identify and isolate volatile requirements by recording,

for each requirement, the probability that it may change

and the probability that it may cause time and cost over-

runs. These volatile requirements and, consequentially,

other requirements that are derived from them or with

which they are associated, can be closely monitored and

their implementation can be delayed until such time as

they become clearer and more stable (see Fig. 5).

All authorised editors of a requirement can collabora-

tively participate in writing it. When the requirement is

formally signed off by its owner(s), it is frozen and

Fig. 4. Class diagram for RM-Tool.


becomes read-only. It is possible to submit Suggestions,

Comments or Change Requests in relation to a

requirement, which are submitted by electronic mail to

the designated requirement owner(s). These can in turn

lead to follow-up actions, which may reopen a

requirement for further revision. Throughout the process,

the document history of a requirement is automatically

maintained, describing who made changes, when those

changes were made and the rationale behind the changes

(see Fig. 6).

Fig. 5. View of user requirements.

Fig. 6. Creating a user requirement through a Web form.


A key feature of RM-Tool is its ability to insert

bidirectional hyperlinks between process specifications,

user requirements and executable Web-based prototypes.

It is therefore possible to trace a user requirement

through to a demonstrated implementation, and back

again. The ultimate benefit of this facility is to improve

communication and understanding between end-users

and developers when verifying and validating require-

ments. Comments can be submitted back to the RM-Tool

database in relation to prototype demonstrations, which

after consideration may cause the related user require-

ment(s) and process specification(s) to be refined or

reworked.

RM-Tool also supports standard structured techniques

for data and process modelling. The specification of a

data structure involves fully describing its attributes, as

well as their data types, validation constraints and

relationships with other data structures. System beha-

viour is described primarily by means of process

specifications, which perform some operation upon the

data structures. If an object-oriented approach is being

taken, it is possible to bundle the data structures and

process specifications together into classes. Because

standard notations are being used, RM-Tool engages a

mechanism to translate the well-defined syntax of these

models into natural language narratives in English, for

the benefit of non-technical users (for example, see

Fig. 7).

5.2. Comparisons with Previous Research

The application of groupware and computer-supportedcollaborative work (CSCW) systems to requirementsmanagement is not new. Previous research effortsinclude those of Macaulay [4] and Dean et al. [14].Perhaps inevitably, our work duplicates that of otherstudies to some extent, but it also sets its own directions.

The prototype developed by Macaulay, a CooperativeRequirements Capture (CRC) tool, is a specialisedelectronic meeting system, the main objective of whichis to facilitate communication amongst a distributed,multidisciplinary group engaged in the early stages of asoftware development project. CRC bears only slightsimilarity to RM-Tool, making direct comparisonsinfeasible. Whereas RM-Tool does not offer the samedegree of group decision support as CRC, it has strongerand richer requirements modelling components.

The tool constructed by Dean et al., consisting of acollaborative Activity Modeler and a Group Data

Modeler, supports their ‘Collaborative Software En-gineering Methodology’. This methodology seeks tocombine the best elements of RAD, JAD, prototyping,information engineering, software reusability and object-oriented techniques into a single methodology. The workof Dean et al. is closely related to ours and is motivatedby similar concerns. However, where RM-Tool differs isas regards its enhanced support for distributed collabora-tion and its support for multimedia data.

Fig. 7. View showing data relationships in RM-Tool.


6. Case Study

In order to validate the extent to which RM-Tool

prototype fulfilled its objectives, it was applied in a

software development project over a time span of five

months (see Fig. 8). Metrics were recorded as the project

progressed, and end-users were polled for feedback and

opinions before, during and after the project.

6.1. Outline of Development Project

The project group consisted of six members: four key

end-users and two lead developers. Two of the end-users

jointly acted as project managers. The end-users were all

familiar with the operational context of the system, but

the developers had little knowledge of it at the outset. Of

the end-users, only one had significant previous

experience in authoring an SRS document. Most of the

end-users indicated that they were incompetent, or were

novices, in the application of requirement specification

techniques. The best-known and best-understood tech-

niques amongst end-users were data flow diagrams,

flowcharts and functional decomposition diagrams.

Furthermore, most of the end-users indicated that they

had little or no experience working with the software

technologies that were identified by the developers at the

outset as being of potential relevance to the eventual

system solution. It was clear therefore that there was

very little overlap between the environments of the users

and the developers, and that effective communication

would be vital so as to facilitate mutual learning and

knowledge acquisition.

The system under development consisted of six

interconnected modules, where each module corre-

sponded to a discrete business function. Responsibilities

were split amongst end-users in terms of level of input

and degree of authority for each of the modules. Initially,

there was some conflict amongst end-users as to who

was the expert for two of these modules, but this

resolved itself by amicable consensus as the project

progressed. Because of the inherent degree of require-

ments uncertainty, an evolutionary prototyping approach

was chosen, whereby requirements analysis activities

continued in parallel with design, coding and testing.

Throughout the project, there was regular contact

between the developers and the end-users. Face-to-face

meetings were conducted fortnightly, and there was

frequent e-mail and telephone communication. All of the

communications were documented in RM-Tool.

6.2. Application of RM-Tool to the DevelopmentProject

Prior to the requirements analysis phase, the end-usershad conducted their own preliminary investigation andhad produced two revisions of a draft document titled‘Functional Specification’, prepared using MicrosoftWord and Microsoft Powerpoint. Although the end-users had made a fair attempt at imposing a template, thedocument was incomplete and contained ambiguities.Some sections, including the Introduction and ProjectScope and Assumptions, were entirely blank. It appearedthat although the end-users were aware that an SRSshould contain explanatory fore-materials, they wereunclear what should be included and how to present suchmaterials.

The initial draft outline of requirements as preparedby the end-users was, by their own acknowledgment,‘very sketchy’. They readily admitted that theirinexperience in authoring such documents and in theuse of specification techniques had been an inhibitingfactor. The draft document included a basic and veryincomplete description of the logical record structures ofrequired system data, as well as mock-ups of screens andreports. There was no glossary or definition of terms,with the consequence that a number of synonyms werebeing used in a confusing and inconsistent manner.

The starting point for the application of RM-Tool wasto parse the draft document, and to import therequirements therein described. A series of face-to-facegroup and individual interviews then took place betweenthe developers and the users during the course of earlyrequirements analysis. The proceedings of these inter-views were recorded, and inputted into RM-Tool in theform of new and amended User Requirements. Asrequirements were input into the RM-Tool database, thedevelopers estimated the level of effort and resourceusage that would be required to implement them. Riskand stability ratings were specified for each requirement,to indicate the probability of time and cost overruns ordrastic change. End-users were asked to allocate a statusfor each requirement: ‘Proposed’, ‘Approved’ or‘Rejected’. Once effort, risk, stability and status hadbeen determined for each requirement, a work schedulewas prepared specifying target implementation dates(see Fig. 5). Only approved requirements were includedin the implementation plan. Requirements that had beenidentified as risky or volatile were deferred until as lateas possible so as to minimise any knock-on effect.

The RM-Tool modelling components were used tocreate data structures and process specifications. UserRequirements were mapped to System Processes, whichin turn were specified using Structured English, screenand report layout diagrams, and flowcharts. These


specifications then formed the basis for coding andprototyping. Hyperlinks were inserted, linking togetherassociated User Requirements, System Processes, andWeb-based Prototypes, so that it was possible to trace arequirement from source through to implementation. TheWeb-based prototypes consisted of animation sequencesdemonstrating simulated interactions, screen-captureimages depicting proposed system interfaces, dataentry validation prototypes using HTML forms andJavascript, and simple HTML mock-ups of systemreports. All comments, suggestions and change requestsmade by end-users in respect to demonstrations ofproposed implementations were logged in RM-Tool.

Throughout the design and coding phases, theimplementation status of requirements (‘Work inProgress’, ‘Complete’, ‘Abandoned’ or ‘Delayed’) wasaccordingly updated in RM-Tool. By browsing RM-Tool’s project management reports, developers and userscould monitor the status of progress in line with theagreed target implementation dates. If delays occurred,the causes were documented by appending Comments tothe affected User Requirements. In this way, any timelags that materialised were clearly visible, as wereindividual responsibilities.

6.3. Management of Changing Requirements

By the end of preliminary requirements analysis, prior tothe start of design, there were 166 unique userrequirements recorded within the RM-Tool database.By the end of design, there were 208 requirementsrecorded. Over the course of the project, a total of 74change requests were logged (see Fig. 8), of which allbut six resulted in modifications to the requirements.Most of these were received during design. Notsurprisingly, as end-users were shown early prototypes,they began to expand the requirements set and altered

existing requirements. The incidence of change requests

lessened as the project progressed, but rose slightly again

during testing.

Most change requests (31%) gave rise to new

requirements that were not included or even alluded to

in the original draft specification. A further 28% of

change requests involved making significant revisions to

previously established requirements, arising out of end-

user uncertainty. Quite a few of these revisions had

expansive scope, as they impacted upon common

features that were replicated throughout each of the six

separate modules of the system. Most of these were user

interface issues, and came to the fore in the early stages

of design. The developers were pleased to resolve such

issues at that stage, as otherwise there would have

inevitably been much user dissatisfaction at a later stage

and a consequent need for tedious rework.

Fifteen per cent of change requests referred to

extensions to requirements that had been defined in the

initial specification. These were mostly minor issues,

such as the inclusion of extra fields on a screen or a

report. Coding errors during prototype construction gave

rise to a further 12% of total change requests. Another

9% were in relation to requirements that were no longer

deemed relevant – for the most part, these were simple

issues, such as removing a field from a screen or report

because it was considered excessive or redundant.

Of the total number of change requests, 33% referred

to the user interface. This was not surprising, as a key

feature of the system under construction was a capability

to organise and present management information in a

meaningful way. In the words of one end-user, ‘The

interface is not merely cosmetic . . . for us, the interface

is the system!’ Twenty-six per cent of all change

requests were in relation to data maintenance require-

ments, and a further 23% referred to reporting

requirements. At the date of delivery, which was

marginally behind schedule, all but eight of the change

requests had been resolved. By mutual agreement

Fig. 8. Smoothed graph showing incidence of change requests by project phase.


between the developers and the users, implementation ofthe outstanding requests was deferred to the nextdevelopment cycle.

7. Analysis and Evaluation

As earlier set forth, we consider the most significantfactors that impede current requirements tools in theirsupport for a truly collaborative requirements manage-ment process to be (1) usability and comprehensionissues for non-technical users; (2) imbalanced choice ofspecification techniques; and (3), lack of support forcollaborative work. These impediments motivated thedesign of RM-Tool, the objectives of which are:

. to facilitate improved communication and under-standing of requirements amongst all project stake-holders by providing a balance between technical andnon-technical specification techniques;

. to facilitate enhanced collaboration between devel-opers and end-users during requirements definitionand verification;

. to engage a mechanism to control the impact ofchanges to requirements.

In the next part of this paper, we evaluate the extent towhich RM-Tool fulfilled these objectives.

7.1. Perceived Outcomes of CollaborativeApproach

All of the stakeholders were of the opinion that the highdegree of collaboration effected by the application ofRM-Tool was advantageous, and gave rise to thefollowing benefits:

. Improved knowledge exchange from developers toend-users – the end-users had limited technicalknowledge at the outset of the project. Thisconstrained their expectations of what was possible.As their perceptions about the limits of technologybecame better informed, expectations became morerealistic in terms of what was technically feasible.Some expectations had been naıvely optimistic at theoutset, while others were subdued. Therefore, somerequirements were discarded as the end-users came toaccept that the benefit of their implementation wouldbe disproportionate to the time, cost and effortrequired. In addition, many ‘new’ requirements wererevealed, as end-users saw what was possible.

. Improved knowledge exchange from end-users todevelopers – the developers had a poor understanding

of the application domain at the outset. As the projectmoved on, they became more familiar with theapplication domain and felt less disorientated.

. Realistic timeframes – as the end-users and thedevelopers worked together to define benefit, risk,stability and effort for each requirement, it waspossible to prioritise requirements by a projectedrelease date, which was feasible.

. Improved quality of delivered software – the end-users felt that the severity of errors throughout theproject was not significant. Because of the high levelof communication between the developers and theend-users, many errors were trapped soon after theirintroduction. In particular, the mechanism for mana-ging change requests was vital to project success, as ithighlighted and rectified problems with the userinterface which, if left undetected, would ultimatelyhave negatively impacted system usability.

. Misguided actions were prevented – end-users alsobelieved that regular communication with the devel-opers helped to quickly clarify misconceptions held bythe developers, which could otherwise have resultedin wasteful efforts.

7.2. Summary of Stakeholders’ Impressions ofRM-Tool

The general impressions of RM-Tool as expressed bystakeholders were that:

. It was extremely useful for documenting the logic andrationale of decisions, and for recording comments,suggestions, change requests, follow-up actions, andthe proceedings of meetings. If a requirement wasmodified, the change history could be recorded. Forsome modules, there was only one expert user, andthere were times when that user was unavailable or onholiday. At times when the expert user was absent,RM-Tool served as an invaluable databank oforganisational memory, rather than having to dependon inconsistent and fuzzy recollections.

. Conflicts of opinion were forced to the surface, andbecause everything was documented the problem ofgoing round in circles was controlled.

. Better project management was facilitated, as RM-

Tool forced users and developers to work out animplementation schedule in a disciplined way thatmaximised benefit and minimised risk.

. Communication was improved, because RM-Tool

permitted the dual expression of requirements usingboth user- and developer-favoured techniques.

. The capability of hyperlinking a requirement, ascaptured from the end-user, to an executable


demonstration of that requirement was also regardedas being of communicational benefit, although it didconsume more of the developers’ time.

The following misgivings about RM-Tool were ex-pressed:

. It required discipline in its application. End-userswere rather loose and casual when describingrequirements or submitting comments, and alsotended to rely on oral communication. Because ofthis general hesitation to produce accurate anddetailed documentation, and a lack of discipline thatcould not be enforced, RM-Tool was constrained.

. End-users cannot be expected to become good writersof requirements without receiving the necessarytraining. RM-Tool does not provide this training,although it helps end-users to learn the requirementsmanagement process.

8. Conclusions and Further Work

This paper is founded on the argument that acollaborative approach to software requirements man-agement is necessary in modern systems development,so as to improve communication between projectstakeholders and thereby bring about improvements inproductivity and quality. Because of the complexity ofsoftware development projects, and also becausestakeholders are likely to be geographically distributed,the use of an automated tool to support suchcollaboration is essential. To this end, a prototype wasdesigned and validated by the authors in a case study.The case study findings support the view that

collaboration between developers and users can improveknowledge exchange, reveal latent requirements, betterinform expectations, assist with early detection of errors,and improve planning and decision-making. Further-more, it was observed that the application of acollaborative tool to support the process of requirementsmanagement can result in improved project manage-ment, better management of organisational memory, andbetter communication and understanding. However, thebenefits of a collaborative tool will certainly be limitedunless there is a firm quality ethos and disciplinedworking methods. Additionally, a collaborative toolseems unlikely to be alone capable of managing thecomplex social processes that characterise softwaredevelopment, so there may always be a need forpersonal human intervention.An obvious drawback of this research is that it is

based on an individual case study, and although the

timescale was realistic the project team was quite small.This may be a basis for future work, to examine theextent to which collaborative requirements managementtools such as RM-Tool are scalable. Another questionworthy of research is whether or not a collaborativedevelopment approach such as that described is suitablefor all categories of systems, or perhaps it may be moreapplicable to business information systems.

References

1. Adler RB, Rodman G. Understanding human communication(3rd ed). Holt, Rinehart & Winston, London, 1988

2. Faulk SR. Software requirements: a tutorial. In: Thayer RH,Dorfman M. (eds). Software engineering. IEEE ComputerSociety, Los Alamitos, CA, 1996, pp 82–103

3. Gray EM, Rao G. Software requirements analysis and specifica-tion in Europe: an overview. In: Thayer RH, McGettrick AD(eds). Software engineering: a European perspective. IEEEComputer Society, Los Alamitos, 1993, pp 78–96

4. Macaulay L. Co-operative requirements capture: prototypeevaluation. In: Spurr K, Layzell P, Jennison L, Richards N(eds). Computer support for co-operative work. Wiley, Chiche-ster, 1994, pp 169–194

5. Hofmann HF. Requirements engineering: a survey of methodsand tools. Working paper no. 93.05, March 1993, Institut furInformatik der Universitat Zurich

6. Holtzblatt K, Beyer H. Making customer-centred design work forteams. Commun ACM 1993;36(10):93–103

7. Davis A, Overmeyer S, Jordan K, et al. Identifying and measuringquality in a software requirements specification. In: Proceedingsof the first international software metrics symposium. IEEEComputer Society, Los Alamitos, CA, 1993, pp 141–152

8. Kar P, Bailey M. Characteristics of good requirements. In:Proceedings of the 6th international symposium of the NationalCouncil on Systems Engineering, INCOSE, 1996

9. Sommerville I, Sawyer P. Requirements engineering: a goodpractice guide. Wiley, Chichester, 1995

10. Place PRH. Unstable requirements: a position paper. In:Requirements engineering and analysis workshop proceedings.Tech. rep. CMU/SEI-91-TR-30. Carnegie Mellon University,Software Engineering Institute, Pittsburgh, 1992.

11. Reich Y, Konda SL, Levy SN, Monarch IA, Subrahmanian E.Varieties and issues of participation and design. Design Studies1996;17(2):165–180

12. Scharer L. Pinpointing requirements. Datamation 1981; April:139–151

13. Booch G. Leaving Kansas. IEEE Software 1998; January-February:32–35.

14. Dean DL, Lee JD, Pendergast MO, Hickey AM, Nunamaker JF.Enabling the effective involvement of multiple users: methodsand tools for collaborative software engineering. J Mgt InformSyst 1998;14(3):179–222

15. Standish Group International. Special COMPASS report onrequirements management tools. West Yarmouth, MA, USA,1998.

16. Jones DA, York DM, Nallon JF, Simpson J. Factors influencingrequirement management toolset selection. In: Proceedings of the5th international symposium of the National Council on SystemsEngineering, Vol 2, INCOSE, 1995

17. Ryan T, Sumner M. The Impact of CASE: can it achieve criticalsuccess factors? J. Syst Mgt 1994;45(6):16–21

18. Sharma S, Rai A. CASE deployment in IS organizations.Commun ACM 2000;43(1):80–88


Documents

A Tool to Support Collaborative Software Requirements Management