INCOSE Tools Database WG - Requirements Mgmt. Tool Survey
RESPONSE: Igatech Systems Pty Limited - RDT
Outline
1. Capturing Requirements/identification
1.1. Input document enrichment/analysis
Using existing document information (such as glossary, index, etc.), aid the user in requirements analysis, identification of requirements, etc.
FULL:
RDT is able to capture glossary, index, etc information into the database either manually or automatically using the Document Import Parser.
1.1.1. Input document change/comparison analysis
The ability to compare/contrast two different versions of a source document
FULL:
RDT Version 3.0 provides full change/comparison analysis integrated in the tool.
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:
RDT provides an optimised import parser capable of importing text documents, and identifying of requirements by key words, structure, unique identifiers, etc. to create requirements from the text.
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:
RDT’s import parser caters for fully automated, semi automated (suggests), and manual identification of requirements from the import file.
1.4. Manual requirement identification
A manual means of identifying or creating requirements.
FULL:
Manual requirements entry is done using edit features within the tool, and/or with cut and paste from external documents.
1.5. Batch mode operation
A mechanism for inputting/identifying requirements from outside of the tool.
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:
RDT V3.0 implements extensive Change Control functionality and check-in/check-out capabilities.
1.6. Requirement classification
Does the tool have the ability to classify/categorise requirements during identification?
FULL:
Requirement attributes allow requirements to be tagged and classified during identification.
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:
RDT provides full capability to capture architecture, functional decomposition, WBS in graphical format and can display data as a tree view of requirements.
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:
RDT provides full capability to capture architecture, functional decomposition, WBS in textual format and can display data as a tree view of requirements.
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:
RDT supports full many to many mapping of requirements through the mandatory entry of related derivation data.
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:
Data linking is flexible to allow ability to allocate portions of that performance requirement to system elements.
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:
Linking can be performed at the point of data entry or later, and there are no restrictions to the direction of the link.
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:
Requirements may be linked to other requirements or to tests with no link restrictions. The tool however enforces that rationale be entered where ever requirements are linked to other requirements or tests.
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:
RDT provides integrity checks and reports to satisfy this need. Examples include orphan requirements and tests, requirements without parents, or without children.
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:
A graphical interface provides this. Users can open Parent, grandparent, child and grandchild traceability windows. Furthermore, reports showing this information can be printed.
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:
RDT includes owner, status and date information with requirement entry. With Workgroup Access enabled, RDT logs who entered data and when. Validation procedures can be mapped to requirements to address the method of verification.
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).
FULL:
Calculations may be performed on attribute fields to obtain this information. RDT can be linked to Excel to facilitate this exercise.
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:
RDT V3.0 introduces full change history control, to supplement the existing Workgroup functionality.
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:
RDT V3.0 introduces full baseline functionality, to supplement the existing Workgroup functionality.
5.3. Access control (modification, viewing, etc.)
The requirements should be able to be protected from modification, viewing, etc. by individuals or groups.
FULL:
RDT supports full Workgroup Access functionality, which enables viewing and editing.
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 (490, 2167, etc.).
FULL:
RDT has a fully user definable output document generator format, capable of generating Military and commercial format specifications.
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:
Spell checking is available.
6.3. Presentation output
Once the information is loaded, the requirements management tool should support the generation of presentation quality charts and graphs.
FULL:
RDT supports OLE format data which may include any application supporting this standard. Charts can be generated through Excel, from dynamically linked RDT data.
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:
Documents may be generated such that no further editing is required. This includes figures, tables of contents, etc.
6.5. WYSIWYG previewing of finished output
The tool should allow the user to view the document on-screen in finished format.
FULL:
RDT allows users to view the document on screen prior to printing.
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.
FULL:
Available through use of attributes, and use of filters and queries. (May be printed)
6.6.2. Requirement progress/status reporting
Status reporting on current compliance/non-compliance to various requirements
FULL:
Available through use of attributes, and use of filters and queries. (May be printed)
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:
Queries and filters are user definable and available for all data elements. These can be shared by other users if required, and saved for later retrieval.
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.
FULL:
RDT is a multi-user tool providing multi-access attribute and note data to be shared by concurrent users.
7.2. Multi-level assignment/access control
Access by the team to the database must be tempered by multilevel 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.
FULL:
RDT supports up to 255 concurrent users. Workgroup access prevents users from making changes without the appropriate privileges. RDT V3.0 introduces change proposals which includes the ability to submit changes into an approval cycle (for acceptance/voting) before committing the changes to the tool.
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?
FULL:
Through OLE, RDT will communicate with all OLE compliant applications including Microsoft Excel. RDT is designed to communicate directly with MS Word for document generation.
RDT is designed to integrated with AxiomSYS structured analysis CASE software by STG Inc (http://www.stgcase.com/). RDT also interfaces directly to VFMFocus tender evaluation software by Evalua (http://www.evalua.com.au/)
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:
RDT’s database is ODBC compliant.
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:
RDT’s database is ODBC compliant.
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?
FULL:
External data may be entered in ASCII text, Excel, DBase or RTF format.
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:
RDT databases are fully interchangeable.
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?
FULL:
RDT allows data to be compared with existing data when imported.
9.1. Single user/multiple concurrent users
Is the tool support a single user or multiple concurrent users?
ANSWER:
RDT is multi-user. The maximum number of concurrent users is 255.
9.2. Multiple Platforms/Operating Systems ______?
Which platforms and operating systems does the tool run on?
ANSWER:
Windows 95/98/ME/NT4/2000/XP
9.3. Commercial vs. unique database
Does the tool use a proprietary or commercially available database?
ANSWER:
RDT uses a commercially available database.
9.4. Resource requirements
Please identify hardware/software configuration requirements:
9.4.1. Memory requirements
ANSWER:
32 MB minimum recommended
9.4.2. CPU requirements
ANSWER:
Pentium recommended
9.4.3. Disk space requirements
ANSWER:
60 MB recommended
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?
ANSWER:
Yes
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?
ANSWER:
Yes
10.3. Interactive graphical input/control of data
Does the tool support graphical input and manipulation of data?
ANSWER:
Yes
10.4. Which window’s standard do you follow?
If your tool supports a window’s standard, which one(s)?
ANSWER:
Microsoft Windows
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?
PART:
This feature is only available through OLE Automation.
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.
ANSWER:
ODBC compliant database, OLE data, OLE Automation, IEEE 1220 and derivatives, EIA 632 and its derivatives etc..
12.1. Warrantee
Does your tool have a warrantee, if so what is it?
ANSWER:
Specific to country of sale.
12.2. Network license policy
Does the tool support network licensing (floating, node locked, etc.), if so which license manager?
ANSWER:
RDT licensing is per named user
12.3. Maintenance and upgrade policy
How often are software updates released; are updates separately priced items, etc.?
ANSWER:
RDT has an upgrade policy of releasing a new version every 12 months. Further more, maintenance releases may be issued more frequently with bug fixes. Maintenance may be purchased on a yearly basis and entitles users to the new release and any maintenance upgrades and telephone or email based technical support. Maintenance is optional.
12.4. Online help
Are the users manuals online, is there online help with the tool?
ANSWER:
RDT includes context sensitive on-line help. The on-line help includes the delivered hard-copy manuals.
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 (URL)?
ANSWER:
Yes: Home Page: http://www.igatech.com/systems
Email: rdt@igatech.com
12.6. Phone support
What type of phone support is available from the tool supplier?
ANSWER:
Under maintenance, phone support is available during normal working hours.
13.3. Recommended training time
What is the recommended training time for a user to become proficient in using the tool?
ANSWER:
RDT training is conducted over 2 days. Users are expected to be proficient with using the tool by this time. Training is also available as an on-line course.
14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?
ANSWER:
Customer support.
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