Requirements Management Tools - A brief Comparison by rcm2

Systems Engineering & Requirements Management Tools Selection

Solutions Resources

.	Training Courses
.	Technical Documents
.	News Forum

rcm2 Updates

.	rcm2 New Rail Project
.	Energy Conservation
.	Consultancy

Most of the large complex projects require either the development of completely breakthrough and novel systems, or the integration of many new and legacy systems. During the first phase, it is necessary to elicit requirements from stakeholders, the paying client, user and operators of the final product. The complexity and extended period of development of such projects will result in continual updating, modification and addition to the requirements. It is essential to track the requirements and maintain an accurate and traceable record at all times. During the system design and development stages of the project, various static and dynamic modelling tools are also required to assist with scenario modelling and trade-off analysis.
In the recent past, office tools such as word-processors, spread sheets and relational databases have been used to record and track requirements, with obvious limitations. There are now available a range of object-oriented databases and modelling tools, many of which provide an integrated environment as a solution to the Systems Engineering process needs.

This note summarises the features of each category of tools currently used for requirements management and systems engineering within Major Investment Projects in the UK and world-wide. Three categories with increasing level of sophistication and expense, as well as decreasing level of ease of use, are identified as follows:

Basic Office Tools – Word, Excel, Access

Features
• Ease of use and minimal training. Microsoft Access, a relational database, is the most difficult to master and generally requires an IT consultant for initial set-up.
• Requirements storage capability, information sharing and basic hierarchical structuring.
• Document configuration management and report generation
Limitations
• No requirements decomposition facility. Relational databases, e.g. Microsoft Access, store data in tables with no access control, versioning, structure or multi-user update.
• No traceability within Word/Excel. Within a relational database (Access), link information is stored as table keys, forcing a join to be used to implement traceability. While this approach works with sample-size databases, it does not scale, making traceability report generation a slow, computationally intensive task. (In an object-oriented database, however, links are implemented directly between objects, with the links as objects themselves. This direct access between objects means that traceability report generation becomes an instant operation.)
• Limited size of database for quick retrieval of information.

Requirements Management Tools – e.g. DOORS, Requisite-Pro, RM-Caliber

Features
• DOORS stores data in a powerful, structured, object-oriented (o-o) database, designed to meet the needs of those managing requirements and other structured engineering data.
• The DOORS database scales from notebook computers up to enterprise-scale servers, with the largest customer database being over 1Gb in size.
• Data stored within DOORS database benefits from integrated audit-trail and versioning, as well as true multi-user document updates and access controls.
• Import/Export Facilities: Text, word-processing, spreadsheets, graphics, report-writing.
• Multiple views (hierarchical, outline, choice of attributes, filtered and sorted data).
• In a relational database, all information is stored in a flat list. Each item must be treated independently. Structured o-o techniques, however, allow key operations to be performed in a natural, hierarchical manner e.g. through ‘inheritance’.
Limitations
• No integrated system modelling capability, except by interfacing to third-party software.

Systems Engineering Tools – e.g. CRADLE, CORE, SLATE

Features
• Integrated requirements management, system modelling, software engineering, performance modelling and document management facility.
Limitations
• Specialist user training needs – partly due to Unix Operating System
• Lack of easy Import/Export facilities from word-processors and spreadsheets.

Tools Selection Criteria

Any software tool should ideally have the following characteristics:
• User-Friendliness – Ease of use leading to minimal training needs and to be taken up quickly by discipline engineers
• Integrated Facility –either as an integral part of the package (e.g. Modelling Capability, project lifecycle coverage) or Interoperability – Open standard for ready interfacing with other complementary software (modelling, whole life costing, project management, etc.)
• Support - wide user group activities and conferences for training and technical support, debugging and upgrade, maintenance
• Functionality – Facilities that meet the requirements of the particular project, i.e. fit for purpose!
• Scalability/Upgradeability – Able to be introduced initially as a stand-alone machine and later expand to network-based client-server, etc.
• Maturity and Market Position – Wide usage within industry