INCOSE Tools Database Working Group
Requirements Mgmt. Tool Survey
Last Updated: January 20, 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:
TracerTool Version:
4.1
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.
Full Compliance. Tracer contains a sample project for reference, and provides an online knowledge base and overview of the requirements process.
1.1.1. Input document change/comparison analysis
The ability to compare/contrast two different versions of a source document
Full Compliance. Tracer is designed to take full advantage of the Microsoft Word environment. Tracking changes, and comparing and contrasting of documents can be configured to the needs of the user.
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.
Full Compliance. Tracer allows for parsing of requirements from MS Word format.
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?".
Full Compliance. The user can designate a requirement manually by visually marking the text within MS Word.
1.4. Manual requirement identification
A manual means of identifying or creating requirements.
Full Compliance. Requirements are typed into a MS Word document.
1.5. Batch mode operation
A mechanism for inputing/identifying requirements from outside of the tool.
Partial Compliance. The user can create a new document with MS Word and enter all of their requirements into the document, then add the document to the project, which will then update the requirements.
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
Full Compliance. The user can manually run the update, or Tracer will prompt the user to run it when it determines that the source-link set has changed. The user does not have to re-import anything.
1.6. Requirement classification
Does the tool have the ability to classify/categorize requirements during identification?
Full Compliance. Requirements are categorized by requirement types. The requirement types are user defined, as are the features and the feature values that further define the types.
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.
Full Compliance. Tracer provides multiple views (matrix, tree, allocation) to allow the user to access the requirements visually.
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.
Full Compliance. The system can be constructed
textually. The resulting text is automatically entered into the system as the document is
added to the database.
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.
Full Compliance. Derived requirements are created in MS Word documents and are linked to other requirements.
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.
Full Compliance. The requirements are grouped by requirement type. The requirement types are user defined, and can support any value the user specifies.
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.
Full Compliance. All linkages support bi-directional capabilities.
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.
Full Compliance. Tracer allows the user to enter notes, rational, accountability, and other related information in the documents that contain the requirements. This flexibility allows images and other related information to be stored as well.
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).
Full Compliance. Tracer allows for the user to view childless requirements, and orphans with an included report.
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
Full Compliance. The user can view the links by running a requirement summary or in one of the views. The user can go directly from a view to the document by double clicking on the requirement within a view.
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.
Full Compliance. The user can specify requirements that are classified as ‘terminal’. These requirements are then used for verification. The date and user information are captured when the requirement is marked as completed, or changed.
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).
Partial Compliance. The requirements are stored in an access database. The user can enter an SQL command through the interface to view the database in the desired format.
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.
Full Compliance. Tracer maintains a record of the user and date of a changed requirement. The user can enter any additional notes on the associated documents to capture any other information.
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.
Partial Compliance. The user must manually copy the project to another location for base lining. The attributes of all the files can then be set to read-only. This activity will not affect the database.
5.3. Access control (modification, viewing, etc.)
The requirements should be able to be protected from modification, viewing, etc. by individuals or groups.
Partial compliance. Documents that are opened once for read/write will not only be available for read access until closed. Access control security for the program is currently under development.
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 Compliance. Output is in Word and can then be modified to desired format.
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.
Full Compliance. Fully integrated with MS Word (dictionary, thesaurus, edit, formatting etc.)
6.3. Presentation output
Once the information is loaded, the requirements management tool should support the generation of presentation quality charts and graphs.
Full Compliance. The program comes with the ability to run some common reports and views. Additionally, the user can export any data from access database to whatever format they desire.
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.
Full Compliance. Integrated with MS Word.
6.5. WYSIWYG previewing of finished output
The tool should allow the user to view the document on-screen in finished format.
Full Compliance. Integrated with MS Word.
6.6. Status reporting
Tool users need to status information in the requirements management tool.
Full Compliance. Closure report included in Tracer. SQL interface available for other statuses
6.6.1. Technical Performance Measurement status accounting
Status current technical performance of various allocated performance requirements and monitor progress towards goals.
Partial Compliance. Each requirement can have a status field that will show progress. A view can be created to display this field for requirements.
6.6.2. Requirement progress/status reporting
Status reporting on current compliance/non-compliance to various requirements
Full Compliance. Views and reports can be run to determine compliance and non-compliance.
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.
Full Compliance. SQL interface allows the user to enter to query entire database. The help file contains a map of the database, allowing the users to run their own queries.
6.7 Support for generation and display of special character sets, mathmatical symbols and formulas, and scientific notation,etc.
Full Compliance. The tool supports any Microsoft add-in for character sets. Documents can be done in any language.
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.
Full Compliance. Client server design allows for multiple users. One user at time is allowed to update a document that contains the requirements.
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.
Partial Compliance. Each user can open a copy of a document locally and make changes to it. When the global version of the document becomes available for ‘writing to’ they can save their changes.
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.
Partial Compliance. Network security can be employed for access control of documents and database.
8.1. Inter-tool communications
Requirements management must have the ability to communicate requirements to other domain-specific design tools (CASE, EE, etc.).
8.1.1. Interfaces to other tools?
What tools will your requirements management tool interface with or talk to?
Given the database structure of Tracer, the data can easily be exported to any format or style the user desires with relative ease. Customization of the data can be done by the user, or contracted from RBC.
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 Compliance. MS Access database.
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?
Full Compliance. Interface for user SQL entry included in program.
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?
Partial Compliance. The user can import the data into MS Word and format the text and then import it into Tracer. Another option is to contract the importation out to RBC.
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?
Full Compliance. Client server architecture allows for the user to open up different databases that can be located in places on LAN.
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?
Not in current implementation.
9.1. Single user/multiple concurrent users
Is the tool support a single user or multiple concurrent users?
Multi-User
9.2. Multiple Platforms/Operating Systems?
Which platforms and operating systems does the tool run on?
Single platform. Microsoft network environment (peer-to-peer, NT)
9.3. Commercial vs. proprietary database
Does the tool use a proprietary or commercially available database?
Commercial, MS Access database.
9.4. Resource requirements
Please identify hardware/software configuration requirements:
9.4.1 Memory requirements (MB)
16 Mb
9.4.2 CPU requirements
200 MHz or greater
9.4.3 Disk space requirements (MB)
5 MB
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?
Full Compliance.
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?
Partial Compliance. The program will update the database that the views are generated from when it detects that changes have been made.
10.3. Interactive graphical input/control of data
Does the tool support graphical input and manipulation of data?
Full Compliance. The user can cut/copy/paste within Word, and change the requirement type within the program through the user interface.
10.4. Which window’s standard do you follow?
If your tool supports a window’s standard, which one(s)?
Microsoft Standard.
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?
Partial Compliance. User can record scripts and macros within Word and then run them as desired.
10.6. Web browser interface
Does the tool allow a user to access the tool or database with a web browser?
Partial Compliance. Documents can be exported to HTML. The Tracer database is not viewable via a web browser with the current implementation
10.7 Undo Function
Does the tool incorporate an Undo feature? Is it multi-level?
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.
Microsoft access database standard. Microsoft Windows 9X, NT 4x, 2000 standard.
12.1. Warrantee
Does your tool have a warrantee, if so what is it?
30 day money back guarantee
12.2. Network license policy
Does the tool support network licensing (floating, node locked, etc.), if so which license manager?
Tool sold on number of concurrent seats that will be in use at one time.
12.3. Maintenance and upgrade policy
How often are software updates released; are updates separately priced items, etc.?
Updates available from company web site, and are included as part of the maintenance agreement.
12.4. Online help
Are the users manuals online, is there online help with the tool?
Users manual, overview manual and online help provided with the tool.
12.5. Internet access/World Wide Web home page location
Does the tool supplier have an Internet e-mail address or World Wide Web home page location? If so, what is the address and Uniform Resource Locator (URL)?
12.6. Phone support
What type of phone support is available from the tool supplier?
Phone support is available from 8:00 am to 6:00 pm central time.
12.7 User's Groups
Does a User's Group exist? If so, who is the primary contact?
Not currently
13.1 Are tools specific training classes available? What geographical areas?
Yes. We are located in Kansas City, but can travel to a client site if necessary.
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.
13.4 Can software installation be performed by an individual with only basic training in the tool?
Yes
14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?
We believe that different users have different needs when looking for a tool. To that end, we think that it is important that the market understand and address these different needs. Our product, Tracer, is designed to meet the needs of an organization that relies on cost-effective solutions when performing requirements management. As a successful software consultancy, we have been delivering solutions on time and within budget to our clients for the last seven years using Tracer. Tracer was designed to address the missing functionality in other products, while not overburdening it with utilities that were not critical to the requirements management process.Return to INCOSE Home
Content Owner: TDWG Chair
Contact us at info@incose.org
Copyright 1998-2004 International Council on Systems Engineering
Last Modified: September 22, 2004