INCOSE Requirements Management Tools Survey

INCOSE Tools Database Working Group

Requirements Mgmt. Tool Survey

Last Updated: January 20, 2000 January Business Meeting, Mesa, AZ

Please identify which version number (1.0, 3.5 etc.) of the tool this survey refers to.  Please respond to each question with a Full, Partial or No Compliance answer.  Additional text may be included for further explanation.

New or revised questions for 2000 are highlighted.

Previous responses and summaries can be located at the INCOSE Web site at URL www.incose.org/tools

Tool Name: DOORS

Tool Version: 6.0

1.      Capturing Requirements/identification

1.1.      Input document enrichment/analysis

Using existing document information (such as glossary, index, etc.) aids the user in requirement analysis, identification of requirements, etc.

Automatic input parsers analyze text for keywords and create attributes for recognized data such as references and

security classification. Following parsing requirements can be automatically labeled based on any search criteria.

Full

1.1.1.   Input document change/comparison analysis

The ability to compare/contrast two different versions of a source document

The spreadsheet import does automatic updates of new versions. Other parsers may be user modified to compare existing with new data.  Also, a document copmare function can be used to compare two documents that have bee nseparatly imported.

Full

1.2.      Automatic parsing of requirements

A mechanism for automatic identification of requirements by key words, structure, unique identifiers, etc. to create requirements from the text.

Multiple parsers are available to read all kinds of data. All parsers may be configured to fit the users' particular needs.

Full

1.3.      Interactive/semi-automatic requirement identification

The ability to identify requirements from a text file via interactive means such as mouse highlighting of the requirement text or prompting by the system “is this a requirement?”.

Automatic parsers will recognize requirements without intervention unless input data is ambiguous in which case the user will be prompted.

Full

1.4.      Manual requirement identification

A manual means of identifying or creating requirements.

Full

1.5.      Batch mode operation

A mechanism for inputing/identifying requirements from outside of the tool.

Full batch loading of requirements from multiple source formats is provided.

Full

1.5.1.   Batch-mode document/source-link update

Does the tool have the ability to update existing linked documents from new/changed versions of the source documents without having to re-establish traceability links

Requirements that are updated, either directly or in batch operations, retain their links. New versions of documents may be used to update the requirements, however, the use of constant requirements identifiers in the source documents significantly aids the process. It should be noted however, that DOORS provides a fully featured Microsoft Word-like editing environment to negate the need for external modification and in many instances remove the need for repeated update from external sources. Where needed links can also be loaded in batch mode from external files.

Full

1.6.      Requirement classification

Does the tool have the ability to classify/categorize requirements during identification?

Automatic text input parsers analyze text for keywords and create attributes for recognized data such as references and security classification.

Full

2.      Capturing system element structure

Once the requirements have been captured, the allocation of requirements to sub-system elements takes place.  The tool must capture these elements so links/allocations can be made to those sub-systems elements.

2.1.      Graphically capture systems structure

Can the tool graphically capture system implementation (such as architecture, functional decomposition, WBS, etc.) and display them graphically such that requirements can be linked to them.

Information from other tools may be displayed graphically depending upon the nature of that data, e.g. a design may be displayed as a hierarchical decomposition and project data from Microsoft Project is displayed graphically to enable links to WBS data.

Full

2.2.      Textural capture of systems structure

Can the tool textually capture system implementation (such as architecture, functional decomposition, WBS, etc.) and display them textually such that requirements can be linked to them.

Data may also be displayed textually if the user prefers to work in that mode. Links maybe made to textually displayed data, e.g. a WBS may be displayed and linked textually.

Full

3.      Requirements flowdown

Once the requirements have been captured and system architecture captured, requirements are allocated to the various system elements.

3.1.      Requirements derivation (req. to req, req. to analysis/text)

The ability to derive/create additional requirements and link between them such as requirement to requirement, or requirement to text (representing trade studies) to derived requirements.

Derived or additional requirements may be created directly  using DOORS' full requirements editor or using decomposition tools to automatically allocate, sub-divide or combine requirements or other data. Links are created automatically by the tool when this is done.

Full

3.2.      Allocation of performance requirements to system elements (weight, risk, cost, etc.)

The ability to link performance requirements to system elements such as weight, cost, throughput, etc.  This also includes the ability to allocate portions of that performance requirement to system elements.

May be achieved using attributes associated with the requirements or independent data linked to the requirements. Performance metrics and other calculations may then be performed on the data. Metrics and other numerical data can be calculated/allocated/dispersed between requirements or other data at the same level or across different levels through links.

Full

3.3.      Bi-directional requirement linking to system elements

The linking of requirements to system elements can be accomplished from either end of the link--from the implementation back to the requirement or from the requirement down to the system element.

This is the natural way of working in DOORS and very little difference is made between linking up, down or at the same level. Note that linking is done through a simple drag-and-drop approach within the same document or between documents.

Full

3.4.      Capture of allocation rationale, accountability, test/validation, criticality, issues, etc.--if so how and what mechanism does it use?

Also critical, is the ability to attach rationale, assignments, criticality, test/validation and many other issues to the requirement, allocation, and the system element to which a requirement is linked. 

All rationale, test/validation, critical issues may be associated with the requirements using assigned attributes or other associated objects in the database. Importantly, this information may also be associated with the link directly as well as the object/requirements itself so that relationships may include a rationale. If required, DOORS can be set to prompt the user for rationale, etc, upon creation or change of any requirement or data object.

Full

4.      Traceability analysis

Once the allocations are complete, the user will want the ability to see the links where they come from, where they go, and why they apply.

4.1.      Identify inconsistencies (orphans, if so what kind of...)

The tool should allow the user to identify inconsistencies such as unlinked requirements or system elements (orphans).

DOORS can identify objects/requirements with no links at all, with no outward links or with no incoming links or with no links of certain type. This can also be conditional on other data types. For example, show all unlinked tests that have not yet been performed or all links to failed tests.

Full.

4.2.      Visibility into existing links from source to implementation--i.e. follow the links

With the requirement links in place, the user needs the ability to follow the links to see where they come from and where they go to

Link analyses (up, down or sideways) may be performed from any starting point throughout the entire chain of links. This may be performed on line or printed in the form of a matrix style report. DOORS also offers the users visible "link-tips" to show links directly in the document and traverse them with the simple click of the mouse. Importantly DOORS can show an unlimited number of link traversals on the same screen at the same time for powerful analysis. Links are also visible in exported HTML versions of the documents and in data viewed directly via the Internet/Intranet using DOORSnet.

Full

4.3.      Verification of requirement (was it done, how was done)

Throughout the life of the project, the requirement management tool will be used to verify that the requirements have been met.  The tool should provide the ability to document that the requirement was fulfilled, how it was done, and who was responsible.

This is achieved by the use of links and/or attributes and is the whole basis for using DOORS.

Full

4.4.      Requirement performance verification from system elements (roll up of actuals)

Once performance requirements have been allocated to system elements, the requirements management tool should support the verification of those requirements by rolling up actuals and reporting on variances (this is the allocated weight versus the actual weight).

Pre-written scripts provided in the DOORS library support roll up values either within a set of requirements or across data linked from many modules. Analysis may also be automated to highlight requirements or other objects where actuals exceed allocated values. If necessary, such discrepancies may be automatically e-mailed to key users. DOORS also offers a statistics tool to automatically generate graphical displays of metrics or calculated values.

Full

5.      Configuration Management

5.1.      History of requirement changes, who, what, when, where, why, how.

Once requirements have been captured, the requirement management tool should maintain a history of requirement changes, who changed it, when it was done, why it was done, etc.  Some of this tracking could be automatic, others could be procedural such as a rationale for the change and how the change is to be accomplished.

DOORS automatically records who, what (down to the actual attribute changed), when and how automatically. The why can also be captured either through the voluntary entry of data by the user, or forced via DOORS' automated trigger mechanism such that the user would not be able to save the change without entering a rationale. DOORS also supports a full Change Proposal System (CPS) for collecting change requests and formally reviewing them via a CCB before changes get into the documents or data sets.

The CPS is also available in DOORSNet for Internet/Intranet access.

Full

5.2.      Baseline / Version control

At various times the requirements will need to be baselined (saved and locked away).  The requirements management tool should support this along with the ability to compare and contrast between various baselines.

Full baselining is supported as well as the comparison of any two baselines. Baselines in DOORS are saved, locked versions of data sets such as requirements, system elements, tests, etc. that may be viewed, flexibly reported, but never changed.

Full

5.3.      Access control (modification, viewing, etc.)

The requirements should be able to be protected from modification, viewing, etc. by individuals or groups.

Access control in DOORS may be achieved at three levels in DOORS. First, sets of data such as requirements in a document or all test cases may be controlled. Second, individual objects such as a single requirement may be controlled. Third, access controls may be imposed on attributes within objects. For example, users may be able to edit a comments attribute but not modify the allocated cost attribute. Access rights are also inherited by children from parent objects. Access levels include the ability to read, create, modify, delete and control access itself. Further, a mechanism called propagation allows access right to be imposed on documents or requirements not yet in existance.

Full

6.      Documents and other output media

6.1.      Standard specification output (if so what kind)

The requirements management tool should output documentation in various military/commercial standard formats (MIL-STD-490, DoD-2167A, etc.).

Full

6.2.      Quality and consistency checking (spell, data dictionary, )

The tool should also support document quality and consistency checking through spell checking, data dictionaries, acronym tables, etc.

DOORS includes a spell checker on both the UNIX and PC versions. Other mechanisms such as acronym tables may be implemented by the user with DOORS modules making use of the Object Oriented database.

Full

6.3.      Presentation output

Once the information is loaded, the requirements management tool should support the generation of presentation quality charts and graphs.

DOORS can generate color graphs and charts for displaying metrics data, results of calculations and statistics. Examples of such charts produced by DOORS  include a volatility chart showing numbers of changes over time for a document or data set. These charts and graphs can be generated and printed directly from DOORS without the use of an external graphics package.  DOORS document hierarchies may be viewed graphically and traceability may be viewed as "tree" structures in the Traceability Explorer.

Full

6.4.      Custom output features and markings (user definable tables, figures, security markings..)

The tool should support the output of documents in finished form including page security markings, graphics/figures, user definable tables, indexes, etc.

Title pages, contents pages, headers, footers, graphics, etc. are all part of the DOORS output to Postscript printers on UNIX or the Windows Print Manager on PC.

Full

6.5.      WYSIWYG previewing of finished output

The tool should allow the user to view the document on-screen in finished format.

Full

6.6.      Status reporting

Tool users need to status information in the requirements management tool. 

6.6.1.   Technical Performance Measurement status accounting

Status current technical performance of various allocated performance requirements and monitor progress towards goals.

DOORS configurable/programmable attributes allow status monitoring of any held information, either within a document or across links in multiple documents.

Full

6.6.2.   Requirement progress/status reporting

Status reporting on current compliance/non-compliance to various requirements

Links and link attributes combined with configurable/programmable attributes support reporting and statistical analysis of compliance or non-compliance.

Full

6.6.3.   Other ad hoc query’s and searches

The requirements management tool should support ad hoc query’s and searches per the user’s discretion.

DOORS supports searches and queries on any data according to users needs either by sets that fulfill criteria or each next object that meets defined criteria. Serach and filtering can be on attribute value, substring searches or the presence or absence of links.

Full

6.7    Support for generation and display of special character sets, mathmatical symbols and formulas, and scientific notation,etc.

DOORS allows users to insert symbols or special characters into the regular text or into attributes. Word’s equation editor can also be used to create equations and then insert them as OLE objects.

Full.

7.      Groupware

Since Systems Engineers rarely work as individuals, the ability for a team of engineers to look/work on the same information at the same time is critical.

7.1.      Support of concurrent review, markup, and comment

The tool should support a team of engineers reviewing, marking up, and commenting on requirements or implementation alternatives.

This is supported in DOORS through a variet of mechanisms. Each project can choose the most appropriate method for them.

First, DOORS supports multi-user concurrent write access to the same document.

Second, DOORS’ CPS (Change Proposal System) allows proposed changes from multiple users to be reviewed together and either the best taken or a combination generated. This feature is also available through the DOORS web interface, DOORSnet.

Third, DOORS Distributed Data Management (DDM) allows portions of the DOORS database to be taken out, worked on and returned for resynchronization with the database.

Fourth, DOORSrequireIT can be used to extract a document from DOORS into Word. Here, the requirements and their attributes can be managed, modified, deleted and new ones created before returning it to the DOORS database for an update.

Fifth, DOORSnet allows users from remote locations to also participate in the team work by making changes and creating new requirements directly to the DOORS database using the internet or an intranet.

Full

7.2.      Multi-level assignment/access control

Access by the team to the database must be tempered by multi-level access control (i.e. the ability to protect things from being modified).  This also includes the ability to submit changes into an approval cycle (for acceptance/voting) before committing the changes to the tool for everyone to see.

DOORS provides a formal Change Process for submission of proposed changes. Specified users then review proposed changes either on-line (with sign off fields) or by committee (CCB). Accepted changes are promoted into the document or dataset automatically. DOORSnet supports the submission of changes for review from remote locations.

Full

8.      Interfaces to other tools

8.1.      Inter-tool communications

Requirements management must have the ability to communicate requirements to other domain-specific design tools (CASE, EE, etc.).  

DOORS has the most flexible method of inter-tool communication. Not only is there a full API, but the DOORS extension language (DXL) can be used to write imports and exports to other tools in almost any format. DXL being C-like is very easy to learn and use. DOORS on the PC can also use OLE automation for integration such as those used by Microsoft tools.

8.1.1.   Interfaces to other tools?

What tools will your requirements management tool interface with or talk to?

The Telelogic program for interfaces with other tools is the most comprehensive in the industry. We now have over 25 interfaces to the most popular tools for design, analysis, text, CM, etc. For a full list of current interfaces contact a Telelogic representative of visit www.telelogic.com/doors.

Full

8.1.2.   External Applications Program Interface available

To support the wide variety of tools in use by engineers, the requirements management tool should have programmable access to the information contained in the tool’s database (to get access to and deposit information). 

Full

8.1.3.   Support Open database system (standard query access)

Does the tool support Open Database standards such as standard query languages or exchange formats?

The DOORS extension language allows data to be accessed more easily than SQL using standard high level programming techniques. DXL is easily programmable by those conversant with C such that SQL knowledge is unnecessary.

Partial

8.1.4.   Import of existing data from various standard file formats?

Does the tool have the ability to import existing data (such as a ASCII text file containing link information) to create structures within the tool without having to re-enter the information?

DOORS can import information in many forms such as MS-Word, ASCII, Spreadsheet, FrameMaker, Interleaf and RTF, so that structures, attributes and links may be set up automatically without manual input.

Full

8.2.      Intra-tool communication

8.2.1.   Exchange of information between same-tool different installations

Since the tool will be used at different sites and different projects, how does the tool exchange information between different tool installations or databases?

DOORS offers a feature called DDM (Distributed Data Management) where users can export controlled sections of the database with read or read/write access to other databases. Data can be returned to the master database at any time with full merge abilities. Distributed parts can be defined down to the single requirement/single attribute level.

Full

8.2.2.   Consistency/comparison checking between same-tool datasets

Does the tool support comparing/contrasting of different same-tool datasets to allow consistency and verification checking?

DDM (see above) and the import methods provided by DOORS include the capability to compare data to see if it is new or existing. These comparisons allow updating of existing data and creation of new requirements. Updates can show inconsistencies and variations between data sets.

Full

9.      System Environment

9.1.      Single user/multiple concurrent users

Is the tool support a single user or multiple concurrent users?

Multiple concurrent.

9.2.      Multiple Platforms/Operating Systems?

Which platforms and operating systems does the tool run on?

Microsoft Windows 98, 2000, NT 4 (SP6), XP.

Sun Solaris 7 and 8

HP/UX 11

9.3.      Commercial vs. proprietary database

Does the tool use a proprietary or commercially available database?

Proprietary, open object oriented repository.

9.4.      Resource requirements

Please identify hardware/software configuration requirements:

System Requirements – Windows Server

Windows NT, Windows 2000 Professional: 128Mb more than is recommended for the Windows system being used.

Windows 98 not recommended.

40Mb disk space recommended for installation and use.

System Requirements – Windows Client

Windows 98, Windows NT, Windows 2000 Professional: 64Mb using a 200MHz Pentium processor or higher.

30Mb disk space recommended for installation and use.

System Requirements - UNIX

Follow the manufacturer’s recommendation for RAM.

40Mb disk space recommended for installation and use.

9.4.1.   Memory requirements (MB)

9.4.2.   CPU requirements

9.4.3.   Disk space requirements (MB)

10.    User Interfaces

10.1.   Doing one thing while you are looking at another

Does the user have the ability run a report and look at a requirement at the same time?

Yes.

Full

10.2.   Simultaneous update of open views

If the tool allows for multiple windows/views into the tool--does a change in one view automatically reflect in all other views?

Yes.

Full

10.3.   Interactive graphical input/control of data

Does the tool support graphical input and manipulation of data?

Yes.

Full

10.4.   Which window’s standard do you follow?

If your tool supports a window’s standard, which one(s)?

None. Although a Microsoft Windows look-and-feel exists throughout.The DOORS user interface is based on Windows 2000 wherever appropriate.

10.5.   Executable via scripts (recordable) or macros

Does the tool allow the user to create and playback commands or macros that allow the user to automate various tedious tasks?

Automation of tasks is supported through a user configurable language. These automated scripts may then be added as menu items and appear just like other functions of the tool. Alternatively scripts may be run from the operating system command line for batch operation.

Full

10.6.   Web browser interface

Does the tool allow a user to access the tool or database with a web browser?

Yes.

Full

10.7  Undo Function

Does the tool incorporate an Undo feature?  Is it multi-level?

Yes. Single level undo and the ability to revert back to any previous version of an attribute in the history without having to step back through all of the intermediate changes..

Partial.

11.    Standards--which one’s do you comply with?

Which military/commercial standards does your tool comply with--including database standards, output document standards, exchange standards, display/graphics standards, etc. 

None.Full:  Documents adhering to various military and commercial standards in multiple output formats can be produced from DOORS. DOORS also supports the needs of the disabled as defined in Section 508 of the US Disabilities Act. Our development and support teams processes in our product division are ISO 9001 compliant.

12.    Support and maintenance

12.1.   Warrantee

Does your tool have a warrantee, if so what is it?

Yes. 30 days.

12.2.   Network license policy

Does the tool support network licensing (floating, node locked, etc.), if so which license manager?

Yes, FLEXMlm.

12.3.   Maintenance and upgrade policy

How often are software updates released; are updates separately priced items, etc.?

Every 6 months. Usually iIncluded in annual support maintenance price.

12[WLM1] .4.   Recommended training time

What is the recommended training time for a user to become proficient in using the tool?

(moved to new section 13)

12.5.   Online help

Are the users manuals online, is there online help with the tool?

Yes.

12.6.   Internet access/World Wide Web home page location

Does the tool vendor have an Internet e-mail address or World Wide Web home page location?  If so, what is the address and Uniform Resource Locator (URL)?

www.telelogic.com/doors

12.7.   Phone support

What type of phone support is available from the tool supplier?

Varies according to geographics location.Tool support is available during normal business hours in most geographic locations.

12.8  User's Groups

Does a User's Group exist?  If so, who is the primary contact?

Yes. Please visit our website for details.

13. Training

13.1    Are tools specific training classes available?  What geographical areas?

Yes. Please see our website for details.

13.2    Can training be made available at a customer's location?

Yes.

13.3    Amount of training required to become proficient with the tool (number of days)?

One day.

13.4    Can software installation be performed by an individual with only basic training in the tool?

Tool training is not required for installation.

14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?

View and update data in context:  Users should be able to view and update requirements in context (usually a document format) along with other associated data (attributes and traceability). Not having to switch to completely different display models or tools to view and update all the data associated with requirements greatly improves understanding and productivity.

Data model definition: The ability to group logical sets of requirements together in projects or folders and to define the legal relationships between these sets that support the user’s process supports the development of a consistent data model and reduces the learning curve for new project members because they are guided through the process.

Suspect links. The ability to see whether a linked object has changed while viewing the original.The indication that data on which a requirement is dependent has changed without having to change your current context or run a report improves the awareness of change and ability to maintain a consistent data set.

Ease of use: is addressed here to a very little extent. For example, users hsould should care if they can only ever see one requirement at a time. Users should care if they can only see one level of traceability at a time and so on.

Contact Information

Name: Paul Raymnd                     Bill Shaw

                                Director, Field Product Marketing

Address:                                Telelogic

                                11911 Fredom Drive,

                                Suite 280

                                Reston, VA 20190

Phone:                    703-708-14223

Fax:                         703-467-9009

E-mail:                    paul.raymondbill.shaw@telelogic.com

Website URL:       www.telelogic.com/doors