A Tool to Support Collaborative Software Requirements Management

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

Requirements Engineering

A Tool to Support Collaborative Software Requirements Management Michael Lang1 and Jim Duggan2 1 Department of Accountancy and Finance, National University of Ireland, Galway, Ireland; 2Department of Information Technology, National University of Ireland, Galway, Ireland

The system requirements specification (SRS) is a highly dynamic document that grows and evolves throughout a software 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 insufficiently versatile to support collaboration between a multidisciplinary and potentially distributed team of stakeholders. 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 technological challenge, but is also a complex social process, and is arguably the most intensive of all engineering disciplines as regards human communications. Effective communication amongst the stakeholders of a software development project is vital to its success. Conversely, if communication is ineffective, the likelihood of delivering a successful system is remote. In particular, the communication of software requirements is extremely problematic. Often, much of Correspondence and offprint requests to: M. Lang, Department of Accountancy and Finance, Galway, Ireland. Email: michael.lang@ nuigalway.ie

post-delivery maintenance work can be traced to requirements which had been poorly or falsely described in the system requirements specification (SRS), or were missed altogether. Significant productivity gains stand to be realised if communication can be improved. In order to bring about improvement, an effective process and the infrastructure to support it must be provided. This paper is founded on the proposition that the software requirements management process must necessarily be a collaborative activity because of the complexity of communication involved. We argue that presently available requirements management tools are inadequate to support all aspects of such a collaborative process. In view of the shortcomings of commercial tools, a prototype was designed and constructed by the authors, and validated in a case study. This prototype, hereafter referred to as RM-Tool, seeks to manage and control requirements within a process that actively engages multidisciplinary, distributed project teams. It is based upon a multi-user Web-enabled multimedia database, implemented using Lotus Notes groupware.

2. Research Method Drawing from the literature in the areas of requirements management, communications theory and cooperative work systems, the authors derived a core set of requirements that a tool for collaborative software requirements management must address. These requirements were classified as ‘mandatory’ ‘desirable’, or ‘optional’, and were allocated priorities (see Fig. 1). The next step was then to assess the extent to which currently available requirements management tools fulfil these requirements. There are so many commercially available tools that claim to support the requirements

M. Lang and J. Duggan

162

Fig. 2. Model of interactive human communication.

Fig. 1. Research method.

management process (or part of it) that it was neither reasonable nor possible to perform a detailed assessment of them all. The authors therefore adopted an evaluation methodology with the objective of reducing this extensive set of tools to a select few ‘best in class’ products. Tools that did not meet mandatory requirements were automatically eliminated. The remainder then underwent closer inspection, based on the match of product features to prioritised requirements. From this assessment, a shortlist of nine tools was compiled, each of which were subjected to detailed evaluation. These evaluations revealed a number of prevalent weaknesses, which in turn became the motivation for the design of RM-Tool. To validate RM-Tool, it was applied in a case study, for which findings and analysis are presented. A mixture of qualitative and quantitative techniques was used for collecting case study data.

The effective communication of software requirements is a formidable challenge. In the first instance, the conceptual structures of software systems are arbitrary, complex, difficult to visualise and difficult to describe [2]. Secondly, software requirements management necessitates ongoing communication between stakeholders from a diversity of disciplinary backgrounds, all with different levels of expertise, interests and objectives [2–4]. This greatly increases communicational overheads, and raises a need to use a variety of complementary techniques to specify requirements. Thirdly, it is typically the case in requirements definition that, at the outset of a project, the end-user has an expert understanding of the operational context, and the developer has a well-informed grasp of technology, but each may be a comparative novice in the environment of the other [5]. Communication in software development must therefore be an ongoing process, whereby users, developers and other stakeholders continually exchange knowledge, thereby altering perceptions, shifting expectations and eradicating false assumptions [6].

3. Background to the Study 3.1. Aspects of Human Communication

3.2. Communicability of the SRS

There is general agreement on the components of a model of human communication [1]. A key factor in the effectiveness of communication is the similarity between the environments of the sender and the receiver of a message – that is, the closeness of their respective backgrounds and cumulative experience. Individuals with different environments perceive things differently, and this is a principal cause of misunderstandings. In Fig. 2, the ovals denote the scope of the environments of the sender and the receiver. The overlap between these environments signifies shared knowledge and experience – the greater this overlap, the more effective the communication.

The objectives of the software requirements management process are to develop a shared, documented understanding of the requirements (in the form of the SRS), and to enforce a mechanism to control volatility so that the system satisfactorily fulfils requirements at the time of its delivery [2]. In order to induce quality in development, there must be quality in requirements management. Inadequacies in the SRS can have a crippling effect. It is vital that requirements be carefully managed on an ongoing basis. Individually, requirements should be concise, design-independent, feasible, precise, complete, consistent and verifiable. As a whole, a set of

ATool to Support Collaborative Software Requirements Management

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 understandable. 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 understandable 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].

163

3.3. Collaborative Systems Development The importance of user involvement has been seen to be a very significant factor in overall project success. However, experiences indicate that merely involving end-users does not guarantee anything – indeed, user involvement has been observed to have negligible or even negative impacts [11]. The issue is therefore not if users should be involved in systems development, but rather how they should properly be involved. It is generally accepted that users should not become involved in technical design. Rather, the human– computer interaction (HCI) community advocates two potential roles for users: 1. to enable the developers to acquire a detailed understanding of users’ work; 2. to verify that proposed solutions satisfactorily meet users’ needs. Traditionally, working relationships between users and developers have been poor [10]. Users are disenchanted because developers consistently deliver unsatisfactory systems; developers are disenchanted because they are allocated the entire blame for system failures. Furthermore, users and developers have inconsistent objectives: developers want the SRS to be precise, specified in functional terms, and finalised; whereas users expect the SRS to be flexible, open to interpretation, fully inclusive of all their requests, and expandable on an ongoing basis. The formation of a multidisciplinary project team is therefore recommended to reconcile these divergent perspectives and to arrive at mutually agreeable decisions [9,13,14]. For complex projects, it is necessary to integrate knowledge from many disciplines. Approaches that emphasise the integration of upstream and downstream activities through the formation of multidisciplinary teams, such as Rapid Application Development, Facilitated Application Specification Techniques and Concurrent Engineering, have become popular in recent years. Multidisciplinary teams provide the benefits of several viewpoints as stakeholders work together to identify problems, propose solutions, and negotiate different possibilities. With a dynamic, give-and-take approach, the team is empowered to make realistic decisions that achieve the best, most workable outcomes for all [11].

4. Assessment of Requirements Management Tools Most of the advances in software development tools and techniques over the last three decades have focused on

M. Lang and J. Duggan

164

productivity rather than quality, and have been primarily concerned with the work of individuals [13]. What is now required is a means to boost the productivity and quality of work done by teams. Often, these teams are dispersed at geographically distributed sites. Sales of requirements management tools have been growing steadily in recent years [15]. There are so many tools currently on the market that claim to support the requirements management process (or part of it) that it is neither reasonable nor possible to perform a detailed assessment of them all. In order to conduct a meaningful assessment, it is necessary therefore to first identify the core requirements of a tool for collaborative requirements management, and then to evaluate the features of commercial requirements management tools against these requirements.

4.1. Requirements of a Tool for Collaborative Requirements Management The basic requirements of a requirements management tool are well established in the literature [9,16]. Given the emphasis of this study on support for multidisciplinary, distributed collaboration, some further requirements are imposed. In summary, a tool to support collaborative software requirements management must be able to: . maintain uniquely identifiable descriptions of all requirements; . classify requirements into logical user-defined groupings; . specify requirements using textual, graphical, and model-based descriptions, with support for rich media descriptions (such as images and animated simulations); . define traceable associations between requirements; . verify the assignments of user requirements to technical design specifications; . maintain an audit trail of changes; archive baseline versions; and engage a mechanism to authenticate and approve change requests; . support secure, concurrent cooperative work between members of a multidisciplinary team, which may be geographically distributed; . support standard systems modelling techniques and notations; . maintain a comprehensive data dictionary of all project components and requirements in a shared repository; . generate predefined and ad hoc reports;

. generate documents that comply with standard industrial templates, with support for presentationquality output, WYSIWYG preview, and in-built document quality controls; . connect seamlessly with other tools and systems, by supporting interoperable protocols and standards.

4.2. Weaknesses of Current Requirements Management Tools In consideration of these requirements, the authors conducted a review of vendor offerings. As described earlier (see Section 2), a short-list of currently available ‘best-in-class’ requirements management tools was compiled, outlined in Table 1. These tools were then evaluated in detail so as to determine overall strengths and weaknesses. While most of the short-listed tools fulfil all or nearly all of the aforementioned requirements with varying degrees of coverage, a number of prevalent weaknesses were observed, outlined as follows. 4.2.1. Usability and Comprehension Issues for Non-Technical Users

Some tools that are marketed as requirements management tools should properly be classified as systems engineering/CASE tools. Such tools are specifically designed for use by skilled specialists who are proficient both in software engineering methods and the functionality of the tool itself. Because of the complexity of CASE tools, and of the artefacts that they produce, they are not practical for communicating with non-technical stakeholders [14]. Indeed, it has been noted that CASE tools can at times even diminish the effectiveness of communication between designers and end-users [17]. Clearly, the orientation of CASE tools means that they are by themselves inadequate to support a collaborative requirements management process involving multidisciplinary teams. Table 1. Leading requirements management tools Tool

Version

Vendor

CORE Enterprise DOORS Caliber-RM RDD-100 RequisitePro icCONCEPT-RTM SLATE Vital-Link XTie-RT

1.3 4.0 1.0 4.1.1 4.0 3.7 4.1 2.3 3.1

Vitech Corporation Quality Systems & Software Ltd Technology Builders, Inc. Ascent Logic Corporation Rational Software Corporation Integrated Chipware TD Technologies, Inc. Compliance Automation, Inc. Teledyne Brown Engineering

ATool to Support Collaborative Software Requirements Management

165

4.2.2. Imbalanced Choice of Specification Techniques

5.1. Overview of RM-Tool Features

It is recommended practice that requirements should be described using both user-favoured methods (such as natural language) and developer-favoured methods (such as model diagrams) to enhance communication and to achieve a balance between technical clarity and general understandability [9]. Few tools achieve this balance. Some are document-based with support for narratives, annotations and semi-structured natural language descriptions, but provide little or no modelling capabilities. Others, more akin to CASE tools, have strong modelling capabilities but are restrictively rigorous, as they do not permit natural language or other highly expressive media such as rich pictures. Very few support compound multimedia documents.

RM-Tool seeks to manage and control requirements within a process that actively engages multidisciplinary, distributed project teams. The key objectives of RMTool are:

4.2.3. Lack of Support for Collaborative Work

The orientation of quite a few tools is towards the standalone work of individual users, even though the importance of technological support for coordinated teamwork is widely accepted [13, 14]. Of those tools that support collaborative work, none are ideally suited for use by a multidisciplinary, distributed team where the stakeholders have diverse skills and needs. Previous research has revealed that there is little industrial adoption and infusion of automated tools that support coordinated, collaborative software development [18]. CASE repositories are a first step. However, purposeful collaboration requires a higher level of group communication than merely accessing a shared repository. Rather, there must be continual interpersonal engagement so that shared understandings of complex issues emerge. Currently available tools do not offer a sufficiently powerful collaboration mechanism to effectively achieve this.

. to facilitate improved communication and understanding of requirements amongst all project stakeholders by providing a balance between technical and non-technical specification techniques; . to facilitate enhanced collaboration between developers and end-users during requirements definition and verification; . to engage a mechanism to control the impact of changes to requirements. The first and second objectives correlate directly with the observed weaknesses of current requirements management tools. The third objective is a corollary of the first two; given the added dynamism of a collaborative approach, the management of changes to requirements becomes all the more crucial. Figure 3 provides a high-level overview of the functions of RM-Tool and the various roles played by the stakeholders. Although the stakeholders have different types and levels of involvement, note that there is no function that is of interest to only a single stakeholder. RM-Tool was designed with this divergence of viewpoints very clearly in mind. The key features of RM-Tool are that it: . maintains a shared data dictionary within a centralised, multi-user, multimedia database with full Webbased access; . maintains requirement descriptions using both technical and non-technical techniques, with hyperlinks between corresponding descriptions;

5. Prototype Design We see the aforementioned shortcomings as the most significant impediments to effective collaborative requirements management. In an attempt to address these shortcomings, a prototype, RM-Tool, was designed and constructed. It is based upon a multi-user Web-enabled multimedia database, implemented using Lotus Notes groupware. As RM-Tool is a research prototype, its scope is strictly limited. Rather than ambitiously attempting to provide full coverage for all the requirements earlier set forth, it concentrates primarily on those that are presently ill satisfied by commercial tools.

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

M. Lang and J. Duggan

166

. provides basic support for standard modelling notations; . supports the storage and manipulation of rich text and compound multimedia documents, which is especially useful for describing complex requirements and for demonstrating simulated implementations; . supports time- and location-independent electronic communication between a team of stakeholders using secure, authenticated connections; . supports backwards and forwards tracing of requirements, from source through to implementation; . facilitates project management, by allocating priorities, responsibilities and deadlines; . has extensive reporting capabilities, and can generate a hard-copy SRS. RM-Tool does not mandate or impose any formalised methodology or paradigm. Rather, it has components that are capable of supporting process-centred, datacentred and/or object-oriented techniques (see Fig. 4). User Requirements are the focal documents in the RM-Tool database, and are typically described using user-centred techniques such as natural language, use case scenarios, mock-up sketches, and dialogue flowcharts. RM-Tool features a rich-text editor, and can additionally import data in many standard wordprocessor, spreadsheet, and database formats, as well as 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 implementation date. RM-Tool insists that end-users specify a priority (‘Mandatory’ or ‘Optional’) for each requirement, 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 overruns. 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 collaboratively 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.

ATool to Support Collaborative Software Requirements Management

167

Fig. 5. View of user requirements.

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

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).

M. Lang and J. Duggan

168

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

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 requirements. Comments can be submitted back to the RM-Tool database in relation to prototype demonstrations, which after consideration may cause the related user requirement(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 behaviour 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-supported collaborative work (CSCW) systems to requirements management is not new. Previous research efforts include those of Macaulay [4] and Dean et al. [14]. Perhaps inevitably, our work duplicates that of other studies to some extent, but it also sets its own directions. The prototype developed by Macaulay, a Cooperative Requirements Capture (CRC) tool, is a specialised electronic meeting system, the main objective of which is to facilitate communication amongst a distributed, multidisciplinary group engaged in the early stages of a software development project. CRC bears only slight similarity to RM-Tool, making direct comparisons infeasible. Whereas RM-Tool does not offer the same degree of group decision support as CRC, it has stronger and richer requirements modelling components. The tool constructed by Dean et al., consisting of a collaborative Activity Modeler and a Group Data Modeler, supports their ‘Collaborative Software Engineering Methodology’. This methodology seeks to combine the best elements of RAD, JAD, prototyping, information engineering, software reusability and objectoriented techniques into a single methodology. The work of Dean et al. is closely related to ours and is motivated by similar concerns. However, where RM-Tool differs is as regards its enhanced support for distributed collaboration and its support for multimedia data.

ATool to Support Collaborative Software Requirements Management

169

6. Case Study

6.2. Application of RM-Tool to the Development Project

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.

Prior to the requirements analysis phase, the end-users had conducted their own preliminary investigation and had produced two revisions of a draft document titled ‘Functional Specification’, prepared using Microsoft Word and Microsoft Powerpoint. Although the endusers had made a fair attempt at imposing a template, the document was incomplete and contained ambiguities. Some sections, including the Introduction and Project Scope and Assumptions, were entirely blank. It appeared that although the end-users were aware that an SRS should contain explanatory fore-materials, they were unclear what should be included and how to present such materials. The initial draft outline of requirements as prepared by the end-users was, by their own acknowledgment, ‘very sketchy’. They readily admitted that their inexperience in authoring such documents and in the use of specification techniques had been an inhibiting factor. The draft document included a basic and very incomplete description of the logical record structures of required system data, as well as mock-ups of screens and reports. There was no glossary or definition of terms, with the consequence that a number of synonyms were being used in a confusing and inconsistent manner. The starting point for the application of RM-Tool was to parse the draft document, and to import the requirements therein described. A series of face-to-face group and individual interviews then took place between the developers and the users during the course of early requirements analysis. The proceedings of these interviews were recorded, and inputted into RM-Tool in the form of new and amended User Requirements. As requirements were input into the RM-Tool database, the developers estimated the level of effort and resource usage that would be required to implement them. Risk and stability ratings were specified for each requirement, to indicate the probability of time and cost overruns or drastic change. End-users were asked to allocate a status for each requirement: ‘Proposed’, ‘Approved’ or ‘Rejected’. Once effort, risk, stability and status had been determined for each requirement, a work schedule was prepared specifying target implementation dates (see Fig. 5). Only approved requirements were included in the implementation plan. Requirements that had been identified as risky or volatile were deferred until as late as possible so as to minimise any knock-on effect. The RM-Tool modelling components were used to create data structures and process specifications. User Requirements were mapped to System Processes, which in turn were specified using Structured English, screen and report layout diagrams, and flowcharts. These

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 techniques 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 corresponded 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 requirements 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.

M. Lang and J. Duggan

170

specifications then formed the basis for coding and prototyping. Hyperlinks were inserted, linking together associated User Requirements, System Processes, and Web-based Prototypes, so that it was possible to trace a requirement from source through to implementation. The Web-based prototypes consisted of animation sequences demonstrating simulated interactions, screen-capture images depicting proposed system interfaces, data entry validation prototypes using HTML forms and Javascript, and simple HTML mock-ups of system reports. All comments, suggestions and change requests made by end-users in respect to demonstrations of proposed implementations were logged in RM-Tool. Throughout the design and coding phases, the implementation status of requirements (‘Work in Progress’, ‘Complete’, ‘Abandoned’ or ‘Delayed’) was accordingly updated in RM-Tool. By browsing RMTool’s project management reports, developers and users could monitor the status of progress in line with the agreed target implementation dates. If delays occurred, the causes were documented by appending Comments to the affected User Requirements. In this way, any time lags that materialised were clearly visible, as were individual responsibilities.

6.3. Management of Changing Requirements By the end of preliminary requirements analysis, prior to the start of design, there were 166 unique user requirements recorded within the RM-Tool database. By the end of design, there were 208 requirements recorded. Over the course of the project, a total of 74 change requests were logged (see Fig. 8), of which all but six resulted in modifications to the requirements. Most of these were received during design. Not surprisingly, 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 enduser 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 requirements, 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.

ATool to Support Collaborative Software Requirements Management

between the developers and the users, implementation of the outstanding requests was deferred to the next development cycle.

7. Analysis and Evaluation As earlier set forth, we consider the most significant factors that impede current requirements tools in their support for a truly collaborative requirements management process to be (1) usability and comprehension issues for non-technical users; (2) imbalanced choice of specification techniques; and (3), lack of support for collaborative work. These impediments motivated the design of RM-Tool, the objectives of which are: . to facilitate improved communication and understanding of requirements amongst all project stakeholders by providing a balance between technical and non-technical specification techniques; . to facilitate enhanced collaboration between developers and end-users during requirements definition and verification; . to engage a mechanism to control the impact of changes to requirements. In the next part of this paper, we evaluate the extent to which RM-Tool fulfilled these objectives.

7.1. Perceived Outcomes of Collaborative Approach All of the stakeholders were of the opinion that the high degree of collaboration effected by the application of RM-Tool was advantageous, and gave rise to the following benefits: . Improved knowledge exchange from developers to end-users – the end-users had limited technical knowledge at the outset of the project. This constrained their expectations of what was possible. As their perceptions about the limits of technology became better informed, expectations became more realistic in terms of what was technically feasible. Some expectations had been naı¨vely optimistic at the outset, while others were subdued. Therefore, some requirements were discarded as the end-users came to accept that the benefit of their implementation would be disproportionate to the time, cost and effort required. In addition, many ‘new’ requirements were revealed, as end-users saw what was possible. . Improved knowledge exchange from end-users to developers – the developers had a poor understanding

171

of the application domain at the outset. As the project moved on, they became more familiar with the application domain and felt less disorientated. . Realistic timeframes – as the end-users and the developers worked together to define benefit, risk, stability and effort for each requirement, it was possible to prioritise requirements by a projected release date, which was feasible. . Improved quality of delivered software – the endusers felt that the severity of errors throughout the project was not significant. Because of the high level of communication between the developers and the end-users, many errors were trapped soon after their introduction. In particular, the mechanism for managing change requests was vital to project success, as it highlighted and rectified problems with the user interface which, if left undetected, would ultimately have negatively impacted system usability. . Misguided actions were prevented – end-users also believed that regular communication with the developers helped to quickly clarify misconceptions held by the developers, which could otherwise have resulted in wasteful efforts.

7.2. Summary of Stakeholders’ Impressions of RM-Tool The general impressions of RM-Tool as expressed by stakeholders were that: . It was extremely useful for documenting the logic and rationale of decisions, and for recording comments, suggestions, change requests, follow-up actions, and the proceedings of meetings. If a requirement was modified, the change history could be recorded. For some modules, there was only one expert user, and there were times when that user was unavailable or on holiday. At times when the expert user was absent, RM-Tool served as an invaluable databank of organisational memory, rather than having to depend on inconsistent and fuzzy recollections. . Conflicts of opinion were forced to the surface, and because everything was documented the problem of going round in circles was controlled. . Better project management was facilitated, as RMTool forced users and developers to work out an implementation schedule in a disciplined way that maximised benefit and minimised risk. . Communication was improved, because RM-Tool permitted the dual expression of requirements using both user- and developer-favoured techniques. . The capability of hyperlinking a requirement, as captured from the end-user, to an executable

M. Lang and J. Duggan

172

demonstration of that requirement was also regarded as being of communicational benefit, although it did consume more of the developers’ time. The following misgivings about RM-Tool were expressed: . It required discipline in its application. End-users were rather loose and casual when describing requirements or submitting comments, and also tended to rely on oral communication. Because of this general hesitation to produce accurate and detailed documentation, and a lack of discipline that could not be enforced, RM-Tool was constrained. . End-users cannot be expected to become good writers of requirements without receiving the necessary training. RM-Tool does not provide this training, although it helps end-users to learn the requirements management process.

8. Conclusions and Further Work This paper is founded on the argument that a collaborative approach to software requirements management is necessary in modern systems development, so as to improve communication between project stakeholders and thereby bring about improvements in productivity and quality. Because of the complexity of software development projects, and also because stakeholders are likely to be geographically distributed, the use of an automated tool to support such collaboration is essential. To this end, a prototype was designed and validated by the authors in a case study. The case study findings support the view that collaboration between developers and users can improve knowledge exchange, reveal latent requirements, better inform expectations, assist with early detection of errors, and improve planning and decision-making. Furthermore, it was observed that the application of a collaborative tool to support the process of requirements management can result in improved project management, better management of organisational memory, and better communication and understanding. However, the benefits of a collaborative tool will certainly be limited unless there is a firm quality ethos and disciplined working methods. Additionally, a collaborative tool seems unlikely to be alone capable of managing the complex social processes that characterise software development, so there may always be a need for personal 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 the extent to which collaborative requirements management tools such as RM-Tool are scalable. Another question worthy of research is whether or not a collaborative development approach such as that described is suitable for all categories of systems, or perhaps it may be more applicable 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 Computer Society, Los Alamitos, CA, 1996, pp 82–103 3. Gray EM, Rao G. Software requirements analysis and specification in Europe: an overview. In: Thayer RH, McGettrick AD (eds). Software engineering: a European perspective. IEEE Computer Society, Los Alamitos, 1993, pp 78–96 4. Macaulay L. Co-operative requirements capture: prototype evaluation. In: Spurr K, Layzell P, Jennison L, Richards N (eds). Computer support for co-operative work. Wiley, Chichester, 1994, pp 169–194 5. Hofmann HF. Requirements engineering: a survey of methods and tools. Working paper no. 93.05, March 1993, Institut fu¨r Informatik der Universita¨t Zu¨rich 6. Holtzblatt K, Beyer H. Making customer-centred design work for teams. Commun ACM 1993;36(10):93–103 7. Davis A, Overmeyer S, Jordan K, et al. Identifying and measuring quality in a software requirements specification. In: Proceedings of the first international software metrics symposium. IEEE Computer 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 National Council on Systems Engineering, INCOSE, 1996 9. Sommerville I, Sawyer P. Requirements engineering: a good practice 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 Studies 1996;17(2):165–180 12. Scharer L. Pinpointing requirements. Datamation 1981; April: 139–151 13. Booch G. Leaving Kansas. IEEE Software 1998; JanuaryFebruary:32–35. 14. Dean DL, Lee JD, Pendergast MO, Hickey AM, Nunamaker JF. Enabling the effective involvement of multiple users: methods and tools for collaborative software engineering. J Mgt Inform Syst 1998;14(3):179–222 15. Standish Group International. Special COMPASS report on requirements management tools. West Yarmouth, MA, USA, 1998. 16. Jones DA, York DM, Nallon JF, Simpson J. Factors influencing requirement management toolset selection. In: Proceedings of the 5th international symposium of the National Council on Systems Engineering, Vol 2, INCOSE, 1995 17. Ryan T, Sumner M. The Impact of CASE: can it achieve critical success 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