See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4091749

Requirements Management Tools

Conference Paper · October 2004

DOI: 10.1109/ICRE.2004.1335687 · Source: IEEE Xplore

CITATIONS READS

79 450

4 authors, including:

Matthias Weber M. Bittner

Technische Universität Berlin Technische Universität Berlin
46 PUBLICATIONS   416 CITATIONS    8 PUBLICATIONS   87 CITATIONS   

SEE PROFILE SEE PROFILE

All content following this page was uploaded by M. Bittner on 07 October 2014.

The user has requested enhancement of the downloaded file.

 Requirements for Requirements Management Tools

Matthias Hoffmann, Nikolaus Kühn, Margot Bittner

Matthias Weber TU Berlin, Fak. IV
DaimlerChrysler AG Research & Technology ISTI, SWT
{matthias.hoffmann, nikolaus.kuehn, margot@cs.tu-berlin.de
matthias.n.weber}@daimlerchrysler.com

elicitation, derivation, analysis, coordination,

Abstract versioning and tracking of requirements during
the complete product lifecycle.”
Tools for managing systems requirements help The choice of a RM tool is an important and
keeping specifications consistent, up-to-date and sensitive issue.
accessible. Since the requirements for complex systems
are themselves complex information structures that
2. Requirements Management Tools
must be handled in complex process scenarios, there Requirements management tools help to achieve the
are many strong requirements concerning a tool for goals of systematic RM:
managing them. This paper presents a requirements - supporting acquisition, specification, grouping and
catalog for requirements management tools that is attribution of the raw captured requirements
based on substantial project experience (including tool - supporting their derivation to more detailed levels,
evaluation experiences) in the area of automotive as keeping and adjusting attributes
well as aircraft and defense systems. The purpose of - enabling test cases and test environments to be
this catalog is to help users compare and select defined and linked
requirements management tools as well as helping tool - enabling relationships between requirements, design,
providers to direct future tool developments. realization and test to be tracked and traced
- enable distributed development within the
organization
1. Introduction As all large systems development projects have to
Requirements are developed based on the given facts manage large sets of requirements, there is a wide need
of the environment and the mission to be achieved. In for such tools and a number of them have become
the course of a project, they become more concrete, commercially available in recent years. These tools use
more detailed and also more complex. The closer the different concepts, have different capabilities and
specification approaches atomic requirements, the more differing degrees of maturity with respect to their
complex the relationship between them becomes. When applicability in system engineering projects. Since the
the project enters the design, implementation and requirements are used and changed almost throughout
integration phases, the work on requirements does not the development process, changing tools in the middle
end; requirements changes must be handled, the status of a project is an expensive and time-consuming
of requirements must be updated according to the business. In the case of modular product lines, changes
project phase and tracing to other development artifacts are even harder to handle because of the many links
should be established. between projects.
The requirements for a system are already a model To allow a careful selection of tools that looks at all
of the system to be developed, which is mostly too aspects of a product, this paper describes a catalog of
complex to be captured at once by humans. To handle requirements for RM tools. The catalog does not cover
the complexity, a systematic tool supported general aspects of tools selection like price, licensing,
requirements management (RM) must be established. reliability of the vendor, stability, documentation, user-
For use in this paper, we define requirements friendliness etc.. Instead, it focuses on functional
management as follows: requirements for the tools. By publishing a set of tool
“Requirements management is the structuring requirements based on substantial project expertise, we
and administration of information from

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 seek to help stratify some basic RM tool functionality with tools for software design and programming plays a
and influence future tool development. less important role.
The requirements for RM tools are very diverse. Strong market competition leads to high cost
They depend on various factors, most prominently pressures and short product lifecycles. Features and
product domain, project and organization size, the requirements change often and late in the development
amount of reuse and the process maturity. The number process. The effort required to maintain complete
of permutations between these factors is large and no traceability therefore often exceeds the expected
tool can cover all requirements. Nevertheless, we benefits. It is important to decide how much and where
believe that most of the differences can be covered by to trace, to ensure that developers do it correctly.
adjusting priorities and by using different requirements Traceability must be very user friendly. User-
management information models (RMIs), that are friendliness is generally an important requirement for
independent of tools. See references [1] and [2] for tools in such an environment. A significant number of
more on RMIs. One of our most important criteria, tools have received negative feedback from engineers
then, is the possibility of freely modeling the because they lack a user friendly interface.
requirements in the tool. Small organizations often A broader and more detailed description of the
need only a small subset of the predefined attributes current software engineering challenges facing
and requirements types. Large organizations are automotive companies can be found in [3].
interested in using the same tool in many different
projects to save on licensing, installation and user 4. Structure of the Catalog
support costs. Another differentiation is that there are
The ISO/IEC Standard for Evaluation of Software
tools with strong method and process support, and
Products proposes a hierarchical structure of
those with less strict process support. The latter are
requirements for software products [4]. To improve
more suitable for development teams that already have
readability and maintainability, we use exactly three
a high process maturity. There are tools with a strong
levels of hierarchy, which have specific roles. The top
document orientation and others with a strong database
level serves as a grouping by stakeholders. This is not
orientation. The former are often preferred in systems
perfectly disjunctive, but serves a very practical
engineering because the engineers are used to
purpose when evaluating products by reducing the
document-like specifications. The latter’s strength is
amount of text stakeholders must read to get an idea of
that they support highly structured specification
the tool. The second level contains “criteria”. Criteria
writing.
have “requirements” (the third level), which specify
3. Company Context and its Influence on them in a way that can be evaluated exactly. In an
evaluation, the compliance of a criterion is a summary
RM Tool Selection of the compliances of its requirements plus notes about
The detailed requirements outlined here were issues that are not covered by the requirements but
developed in automotive electronics development appeared relevant to the evaluator. The requirements
projects at DaimlerChrysler AG, based on experiences must not completely cover their criterion: The catalog
in aerospace and defense systems. They reflect the focuses on requirements that potentially discriminate
experience gained from feedback loops between tool between tools. All requirements are prioritized with our
evaluators and tool users. Automotive electronics priorities. The priorities "high", "medium" and "low"
products are complex, highly modularized and are indicated by "(++)", "(+)" and "(-)" respectively.
organized in product families. New variants and
products contain relatively little functionality that is 5. Requirements from the Developers
completely new. Tool support for systematic reuse, This section describes criteria and their requirements
versioning and modularization of requirements is that cover the RM tool needs from the system
therefore important. The teams working on the developers’ point of view. They cover the core
specifications are very large. Developers work in functions that make up an RM tool.
parallel on many variants and vehicle projects.
Scalability and efficient project and rights 5.1 Information Model (++)
administration are therefore musts. The RM tool users The tool must allow the user to freely define a RMI.
are more involved in systems engineering than in - Every object in the database must be uniquely
software engineering. This is typical for the automotive identifiable over its lifetime. If a hierarchical or
sector, where most of the code in current vehicles is other structure is in place, it must be independent
written by suppliers according to the OEM’s from the unique identification and adapt
specifications. This means that flexible document automatically. (++)
generation and rights management are important
features of RM tools. On the other hand, integration

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 - The RMI must be changeable during the project. - The tool should support basic text formatting. It
(++) should also support scientific and foreign-language
- Inheritance and reuse should be available for all character sets. The tool should allow mathematical
classes, types and attributes. (+) formulas to be used in the description texts. (+)
- It could be possible to graphically define and - Non-text objects should be saved directly in the
configure the RMI. (-) database or at least in a configuration management
- The tool could support RMIs that are needed when tool that is tightly coupled with the tool. If they are
using standard RE templates (e.g. MIL-STD-490, stored in the tool database, they must be fully
DoD-2167A, INCOSE, Volere or IEEE 830-1998). covered by its version and rights control. (++)
Project templates should be included. (-) - External objects must be viewed either through a
Rationale: Since a RM tool must be independent of pre-viewer inside the tool or in the native application
process and method, the requirements must be modeled if called directly from the tool's user interface. (++)
freely in the tool. The detailed mapping of a process Rationale: Many specifications created with text
and its artifacts to a RM tool can be described using a processing tools like Word contain lots of graphics or
RMI. Experience shows that especially in pilot projects other multimedia elements. Developers expect similar
this mapping varies to achieve a higher benefit from a means of expressions from a RM tool, which must be
RM tool. directly visible in the RM tool user interface.
5.2 Views (++) 5.4 Change Management and Comments (++)
The tool must support various views of the same The tool must offer the possibility to handle formal
data. A view offers the possibility to view and change a change requests. This function must be customizable to
freely defined collection of parts of the data of several the change process of the users and must be integrated
projects or subprojects in a freely configurable into rights management. (This could be seen as an
representation. application of workflow management).
- The tool must allow views to be defined centrally as - The change requests should have public status
well as in a user-specific manner. (++) information like pending, accepted, rejected. (+)
- These views must be freely configurable, including - There could be a comments or discussion function
complex filters on objects, relations, and attributes. tightly linked to the requirements, but outside formal
(++) change management. Users could add comments to
- The objects must be changeable in the current view. requirements and changes to requirements. (-)
(+) Rationale: A tool-based systematic change process can
- The user must be able to view the requirements in a enable reduce errors significantly. Especially in the late
document-oriented manner, i.e. as sequential text phases of a project, a restrictive change management is
with headings, tables, etc.. (++) important. The straightforward changes in earlier
- The user must be able to view the requirements in an project phases must be possible as well.
information-model-oriented (sometimes called
5.5 Documentation of the History (++)
database oriented) manner. Tables or forms are
examples of such a representation. (++) - All changes to the requirements must be tracked and
- Graphical views of the requirements should be kept in the database. (++)
available. (+) - The objects in the tool must be versioned. (++)
- The tool should allow views to be predefined for - There must be a distinction between major and
user roles. In the course of a project, the views and minor versions. (+)
the assignment to roles should be changeable. (+) - The version number should be incremented
- All users must be able to customize the standard automatically when certain changes occur. (+)
views without changing the template. (++) - Changes must be tracked down to the smallest unit
Rationale: Depending on the current process step RM of data structures, in most cases to attributes. (++)
tool users work only on certain aspects of a certain part - Changes and old versions must always be available.
of the specification. It is therefore important, that a RM (++)
tool provides suitable views of the huge amount of - The tool must allow a requirement to be changed
information accessible in RM tools. This has a strong back to any previous state anytime. (++)
impact on the acceptance of the tool by the users. - The tool should visualize the change history in an
appropriate way, e.g. colored version comparisons.
5.3 Formatting, Multimedia and External (+)
files (++) - The tool must generate freely configurable change
The tool must allow the requirements to be enriched reports. These reports should relate to views,
with formatting and objects not native to the tool. baselines and generated documents. (++)

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 - The tool could analyze changes to provide - The tool must feature a practical, user-friendly and
information about the project status. (+) concise graphical representation and navigation of
- A comment should be saved with the change to the traces, g.g, matrices, trees or graphs. (++)
enable it to be understood later on. (-) Rationale: For years traceability has been one of the
- Changes could be categorized for analysis. (+) big discussion and research issues in requirements
Rationale: In the usual highly parallel development, engineering. Certain standards for security-critical
which is needed to reduce time to market, developers fields even enforce complete traceability.
need to synchronize their specifications periodically. Unfortunately, linking is not popular among developers
Differences from previous versions must be easy because it costs time, its benefit is visible mostly in
identifiable. During such synchronization steps later phases, and it needs discipline in linking. Good
discussions reconcilement may be necessary. Due to tool support could change this and enable analyses and
cost and complexity issues it should be possible to consistency support that would otherwise require much
partially return to previous versions. more effort.
5.6 Baselining (++) 5.8 Analysis Functions (+)
The tool must support baselines. A baseline is the The tool should be able to analyze requirements.
state of a (specified subset of the) brequirements Examples are linguistic analysis, analysis of the link
database fixed at a given point in time. Compared with structure, analysis of project progress and risk
object versioning, a baseline is a (partial) database management.
consisting of numerous objects, each in a certain - The tool should provide information about status and
version. The development status saved in a baseline is progress of the project. (+)
the starting point for further development. - The tool should allow to analyze inconsistencies in
Rationale: Baselines are used to save the state of a the link structure like finding gaps in the traces. (+)
specified set of requirements objects, a document or - The tool could scan the description texts of the
project before a larger development step. They also requirements for patterns like unsuitable/inexact
serve to freeze a development object after its language or wrongly used terminology. (-)
completion or review. Baselines are not branches. They Rationale: The enrichment of requirements in an RM
do not copy the objects; they are a catalog of tool with additional information stored in links and
object/version references. attributes allows automatic analyses that would be
costly and time-consuming if done with requirements
5.7 Traceability (++)
saved in ordinary documents.
The tool must enable traceability through links
between requirements. The linking must be 5.9 Tool Integration (++)
implemented in a highly user-friendly manner because The tool must have open interfaces to other tools
it helps only if it is relatively complete. used in the development process and make information
- The tool must be able to enforce the creation or stored in them visible and linkable.
change of certain links upon creation or change of a - Linking must not lead to redundant data. (++)
requirement. (++) - The connection should be transparent in both tools.
- Links must be directed and an object must be a (+)
source and target at the same time (but not of the - Links to external objects should be managed by the
same link). Additionally, the user must be able to tool in the same way as internal links. (+)
create links starting from the source or the target of - The user should be able to navigate to these objects.
the directed link. (++) (+)
- It must be possible to follow links directly in both - Access rights to the external objects must be
directions. (++) recognized. (++)
- It must be possible to give the links attributes, e.g. to - The links should be able to target the smallest
differentiate different kinds of links for later filtering possible structure of the external object (like the
or analysis. (++) attribute of a class in the class diagram). (++)
- It should be possible to create rules governing what - The interfaces used for tool integration should be
kinds of requirements must have links to what other active, i.e. synchronization or change notification
kinds of requirements, if this is not already enforced should occur automatically. (+)
by the information model. (+) - The tool could support tool integration platforms. (-)
- Links must connect any objects in the database, not Tool classes that could be sensibly integrated with
only in the same subset (module, project, etc.) (++) requirements management are:
- Links could be n-ary. (-) - configuration management (++)
- test, validation & verification (++)
- problem tracking (+)

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 - modeling and design (+) - The tool must generate very large documents with
- communication, e.g. e-mail (+) many included external objects quickly. A 5000-
- performance analysis (-) page document with formatting and media objects
- project management (-) should be generated in one night. (++)
Rationale: To improve consistency between - It should be possible to run the document generation
development phases and allows complete traceability automatically as a background task. (+)
over the complete product life cycle RM tools must be - The document generator must be extensible via a
integrated tightly into existing tool environments. The programming interface (or similar) provided by the
expected benefit is an improved development process tool. (+)
and improved product quality. The introduction of a - Access rights must be enforced in the document
RM tool should not result in additional major changes generator. (++)
of the tool environment. Rationale: An RM tool is of no worth without powerful
document generation capabilities. The days of
5.10 Import (+)
paperless development are still far away, especially in
The tool should be able to import existing fields where interaction with suppliers is important.
requirements specification documents (e.g. from MS Specifications are an important part of the contract with
Word), while retaining the structure of the content. the supplier, which is why something document-like is
- The tool should recognize text marks, formatting, always needed, whether it is printed or just a file.
line ends, grammatical structure or keywords to Document generation can be one of the main
interpret them as the beginning or end of productivity-enhancing applications of RM tools, if
requirements texts. (+) developers can generate documents at the push of a
- The tool should support a semiautomatic, i.e. user button and don’t have to carry out detailed formatting
interactive, import of requirements from existing before and after document generation.
documents. (+)
Rationale: Migrating from document-based to tool- 5.12 Collaborative Working on the Same
based requirements management is a tedious task that Development Task (++)
can be partially automated. It can also be a chance to It must be possible for many users to work on the
improve the structure of the requirements specification, same data at the same time. Of the many users working
which is why semiautomatic import is superior to on an object, only one must be able to apply changes. If
automatic import. a user changes an object, it should refresh
5.11 Document Generation (++) automatically in the user interfaces of the other users.
Rationale: It is a typical situation that several users
The tool must be able to generate official and internal work on same or adjacent parts of specifications at the
documents. To achieve this, the tool needs a document same time. Managing the data using a RM tool can
generator that uses predefined document definitions to provide a single source and up-to-date state of the
generate documents with current data from the project for all participants, but fine-grained locks are
database. Document generation differs from document- important not to suspend each others work. Especially
oriented views in that the generated documents are no if users want to reconcile a part of a specification at
longer connected to the database and an independent different locations, e.g. during a conference call, they
document file is created. need an instantaneous feedback of performed changes.
- The subset of data to be included in the document
must be flexibly configurable, comparable to views. 5.13 Checking out for Offline Use (++)
Formatting and positioning must be flexibly It must be possible to check out data and a license to
configurable, too. (++) work on mobile offline computers without sacrificing
- The document generator must be able to include all consistency and access rights.
information available in the tool. (++) Rationale: Although mobile network access is
- The document generator could be able to create constantly improving, it is still far from perfect and
documents in certain standard formats. Templates performance is not yet predictable. In addition, many
for these formats could be included. (-) organizations have security restrictions that do not
- Together with the requirements data the document allow mobile access to the databases.
generator must be able to include meta information
like the change history or ownership in the generated 5.14 Web Access (+)
document. (++) The tool should have a web interface or another
- Non-textual objects must be included in the browser-based client that makes it unnecessary to
generated documents. (++) install a client application for occasional users.
- The generated documents must be in a standard file Rationale: Web interfaces offer a reliable and easily
format. (++) manageable possibility to work with the requirements.

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 They are interesting for collaboration with external partners in the development process increases the
partners (“extranet”) and for internal users that use the importance of this functionality.
tool only occasionally. Nevertheless, in reality most
6.3 Size Restrictions (++)
users are “power users” for whom the native clients
provide a smoother user experience and opening the There must not be an upper limit for the size of the
tool to the web causes some managers and database and the number of requirements, users, groups
administrators headaches. etc. If such limits exist, they must be known exactly.
The database must be able to handle very large
6. Requirements from the Project projects. The database fields should not have a fixed
Administrators size restriction.
- Unlimited size of a requirement (++)
This section describes criteria and their requirements - Unlimited number of requirements (++)
that cover the RM tool needs from the project and tool - Unlimited number of users (++)
administrators’ point of view. They cover issues that - Unlimited number of user groups and roles (+)
are not core functionalities, but essential for large scale - Unlimited database size (++)
projects. Rationale: Large projects in particular benefit from RM
6.1 Central Installation and Administration tools. To pre-estimate the limitations of a new project is
of Projects (++) inaccurate, because it could be the starting point of a
single product or a wide product family.
All project-wide information must be held and
changed at one place. A history of associated changes 6.4 Workflow Management (-)
must be available. The tool could support systems development via an
Rationale: Typically a dedicated group of persons takes administrable, organized and structured process, called
the responsibility for the correct mapping of the process workflow. Information could be provided and rights
specification to the RM tool implementation. They granted depending on the current phase or step in the
must master and document the further development process. The workflow must not simply restrict the
from the initial project installation. Without such a users, but guide them through the process.
responsibility uncoordinated deviations will take place, Rationale: A workflow provides steering mechanisms
which can be very extensive to administrate. which ensure that all needed steps of an activity are
6.2 Users, Roles and Rights (++) completed. Workflows can help to implement a certain
RE process and can improve consistency and
The tool must allow fine-grained administration of standardization of the requirements. Rigidly IT-driven
users, user groups, user roles, user rights and user-roles workflows are very unpopular among high skilled
rights. A history of changes to these must be available. workers and in projects with tight timelines.
- The administrator must be able to manage user
accounts and group and role assignments centrally. 6.5 Extensibility (++)
(++) The tool must be adaptable and extensible to the
- Users must be defined centrally for all projects. (++) needs of the organization or project.
- The tool must allow fine-grained access and writing - The tool must provide an open and well-documented
rights to be flexibly granted. (++) object model and an API which makes all data and
- Security based on overlapping roles is preferred to functions accessible to extensions. Standard
security based on hierarchical security levels. (-) programming languages should be used. (++)
- The security concept must not be compromised by - The object model and the API must be stable across
extensions like API programming or scripting. (++) versions of the tool, even major versions. It should at
- Security among competing suppliers with access to least stay downwards compatible. (++)
the tool is an important issue. (++) - The user interface of the tool must be customizable
- Access rights must be grantable via roles a user is and extensible with a standard script language. (++)
assigned to. (++) Rationale: Every organization has different needs and
- A user must be able to perform more than one role at usage patterns for a RM tool. Often nonstandard or
a time. (++) domain-specific development tools have to be
- Rights must be grantable down to object and integrated with the RM tool.
attribute level. A distinction must be made between
rights to view, propose changes or make changes. 7. Requirements from the Tool
(++) Administrators
Rationale: The bigger and the more critical the project,
the more important user and rights administration This last section of the requirements catalog covers
becomes. Including external and possibly competing the requirements from the IT system administrators for

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 an RM tool. Reliability and data security are the most evaluation of three requirements management tools.
important issues for them. Details of the evaluation and the requirements used
were not published. The report merely states what the
7.1 Database (++)
problems are.
- The tool must use an appropriate database Karl Wiegers published an analysis of the RM tools
technology, which must be scalable and reliable. on the market at that time. It gives a good overview of
- To improve performance, the tool should use a the tools main features and characteristics [6]. He used
database that uses a modeling paradigm similar to 16 requirements in a short text summary to describe the
the one used in the tool, i.e. object-oriented, tools. The requirements are fairly basic and more on a
hierarchical, relational, etc. (+) feature level than on that of a detailed evaluation..
- The database must be available 24h a day and 365 In “The Future of RM tools”, Finkelstein and
days a year. Maintenance work on the database must Emmerich describe and discuss their expectations in
be done on the running system. (++) detail [7]. Now, some 4 years later, nearly all of the
- The database system use must be transaction-safe functions they expected in the short and medium term
and the tool must consistently use this feature. (++) are already available in some or most of the tools on
- The database must have a consistency-analysis and the market. These functions are covered by the
data-integrity check. It must be able to repair such requirements formulated in this paper. For the long
errors. (++) term, they expect solutions for integrating workflow
- It should be possible to run the database backend in into requirements management, for the interplay
a distributed manner. The synchronization between architecture and requirements, for coupling
mechanism of the distributed database should work literate and formal specification and for knowledge
reliably across different tool versions (major and handling. All of these are aimed at more explicit
minor versions). (+) process and method support in the tools, which is not
- To improve data security and availability, the tool our focus.
must use a database that is independent of the tool Reinhard Ploetsch developed a selection process and
and can be administered independently. (++) a requirements catalog for assessing and selecting
- It must be possible to backup and restore only a part requirements management tools [8]. On a high level,
of the data in the database, e.g. just a specific project his requirements are well structured and reasonable, but
or the complete database. This must be possible the detailed requirements he lists in his examples are
while the system is running. (++) often hardly measurable, though he uses the term
- It must be possible to export all project data and to “metrics”. In addition, there is no prioritization of the
import them again at a different time or places requirements, which makes the selection process less
for/with different tool. (++) focused.
- The data should be stored in a universal format. (+) A relatively complete catalog was published by the
Worldwide cooperation in development projects ITEA DESS project [9]. Their requirements are
requires a round-the-clock access to the RM project strongly tailored to the application field of real-time
database. A RM tool database failure can be very embedded systems.
expensive, if developers can’t work and deadlines are The most important and complete analysis of
missed. requirements for requirements management tools we
7.2 Encryption (++) looked at is the INCOSE Tool Survey [10]. The
requirements used in the study are based on an
The information stored in the database of the tool INCOSE Report by Jones et al. that analyses the factors
must not be readable to system administrators or influencing requirements toolset selection [11]. They
intruders. (++) classify process maturity levels, RM tool users and RM
The tool must allow all communication between client tool architectures. Unfortunately, the authors do not
and server to be encrypted. map the requirements formulated later on to these
Rationale: Requirements specifications of upcoming classifications, so that the original intention of creating
products and research prototypes are the main target of a general-purpose set of requirements is not achieved.
industrial espionage. In highly competitive high-tech Also, the requirements used in the study implicitly
markets, this is a major problem. Suppliers have a require a specific RMI and a specific terminology.
strong interest in data security, too. There are, for example, requirements that call for
specific attributes or link types. The second weakness
8. Related Work of the INCOSE Tool Survey is that the tools were
Bjarne Tvete of Thomson-CSF Norcom reports evaluated by the tool vendors themselves. This is not
experience from a requirements management necessarily a flaw, but the requirements used were
improvement project [5]. The project included an formulated for evaluation by an independent. Questions

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
 are mostly of the open-answer type and not very
detailed. Terminology was not defined, so the authors International Conference on Software Engineering (ICSE03),
obtained some strange results when tool vendors IEEE, 2003.
interpreted a feature name in a legitimate but not
[4] The International Standardization Organization, ISO/IEC
intended way, making their tools look fully compliant 9126 : Information Technology – Software Product
but if one takes a closer look this is not necessarily the Evaluation – Quality Characteristics and guidelines for their
case. use, 1991.
Maiden and Ncube published an extensive report on
deriving COTS software selection requirements, which [5] B. Tvete, “Introducing Efficient Requirements
was originated in the context of selecting an RM tool Management”, Proceedings of the 10th International
Workshop on Database and Expert Systems Applications,
[12]. Although they did not publish their requirements 1999.
for an RM tool, their methodology and the “lessons
learned” were helpful in creating this catalog. A more [6] K. Wiegers, “Automating Requirements Management”,
general introduction to issues of software package Software Development, 7(7), July 1999.
requirements and procurement can be found in the [7] A. Finkelstein, W. Emmerich, “The Future of RM tools”,
position paper by Finkelstein et al. [13]. G. Quirchmayr and R.R. Wagner and M. Wimmer (ed):
Information Systems in Public Administration and Law,
9. Conclusion Austrian Computer Society, 2000.

In this paper, we have presented a matured and [8] R. Plösch, “Efficient Assessment of RM tools”,
complete catalog of requirements for requirements Proceedings of the 4th Workshop Iberoamericano de
Engenharia de Requisitos e Ambientes de Software (IDEAS
management tools. The catalog is not only for tool
2001), Instituto Tecnológico de Costa Rica, Centro de
developers but also for those who use such tools. The Información Tecnológica, Serie manuales didácticos, no. 11,
catalog itself is not fixed, rather it is subject to 2001.
periodical review and modification as computer
technology trends or automotive development process [9] L. Bokhorst, “Task 1.8 Requirements Management
trends lead to new or strengthened requirements as well Method D1.8.3 – RM Tools proposal”, Information
Technology for European Advancement – Software
as to weakened or outdated ones. We have described
Development Process for Real-Time Embedded Software
the influence of the automotive background to this Systems (ITEA DESS) Documentation, 2001.
catalog. However, we think that it is quite useful as a
basis for RM tool requirements for other domains as [10] The International Council on Systems Engineering,
well. For example, some of the priorities may reflect “Tools Survey: RM tools”, Available from
automotive experiences and needs, could well be http://www.incose.org/tools/tooltax.html ,
12/2002.
different in other domains.
An evaluation template with some more detail is [11] D. Jones, D. York, J. Nallon, J. Simpson,. “Factors
publicly available [14]. Influencing Requirement Management Toolset Selection”,
Proceedings of the Fifth Annual Symposium of the INCOSE,
Acknowledgments Vol. II, July 1995.

Our thanks go to our colleagues from [12] N. Maiden, C. Ncube, “Acquiring COTS Software
DaimlerChrysler and TU Berlin whose insights and Selection Requirements”, IEEE Software 15(2), 1998, pp.46-
56.
experiences have provided us with the essential input
for writing this paper. [13] A. Finkelstein, G. Spanoudakis, M. Ryan, “Software
Package Requirements & Procurement”, Proceedings of the
References 8th IEEE IWSSD, 1996, pp.141-145.

[1] M. Weber, J. Weisbrod, “Requirements Engineering in [14] http://swt.cs.tu-berlin.de/lehre/eks/

Automotive Development – Experiences and Challenges”,
IEEE Software 20(1), 2003, pp. 16-24.
[2] G. John et al., „Using a Common Information Model as a
Methodological Basis for a Tool-Supported Requirements
Management Process“, Proceedings of the 9th INCOSE
Symposium, A. Fairbairn et al., eds., Ascent Logic Corp.,
Brighton, UK, 1999, pp. 59–67.
[3] K. Grimm, „Software Technology in an Automotive
Company – Major Challenges“, Proceedings of the 25th

Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04)

1090-705X/04 $ 20.00 IEEE
View publication stats