Requirements Mgmt. Tool Survey - QSSRequireit Response
Last Update: January 1999, January Business Meeting, Mesa, AZ
Tool Name: QSSrequireit
Tool Version: 1.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.
Full - QSSrequireit provides users with quick start capabilities (i.e. templates, pre-defined attributes) as well as the ability to immediately work within existing Word documents.
1.1.1. Input document change/comparison analysis
The ability to compare/contrast two different versions of a source document.
No compliance – QSSrequireit does not offer versioning capabilities except for those currently available in Word.
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 – Users are able to mark requirements via a manual or automated process which is done through keyword searches.
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?".
Partial compliance
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.
No compliance – QSSrequireit does not provide this capability but DOORS does support this functionality.
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
1.6. Requirement classification
Does the tool have the ability to classify/categorize requirements during identification?
Full – Using attributes.
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.
Full – Using links
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 – QSSrequireit supports the marking of text, graphics, OLE objects and tables.
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 – See above
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
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.
Full3.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.
Full3.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 – Using attributes
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.
Full – Using traceability reports.
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 – Creating filters and generating reports.
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 – Either through using traceability reports or navigating from source to target documents or target to source documents.
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 – Using attributes.
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).
No compliance.
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.
No Compliance – QSSrequireit does not provide a historical tracking capability but it iscertainly supported in DOORS.
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 – Through the use of MS Word’s version control and track changes (compare documents) functions.
5.3. Access control (modification, viewing, etc.)
The requirements should be able to be protected from modification, viewing, etc. by individuals or groups.
Full – Through the use of MS Word’s password protection capabilities which can be accessed by users who have the tool installed on their individuals PCs. QSSrequireit does not support multi-user access capabilities.
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 – If parsed in but QSSrequireit does not have specific templates available to support these standards.
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 – Through the use of MS Word’s Spellchecker and Thesauraus.
6.3. Presentation output
Once the information is loaded, the requirements management tool should support the generation of presentation quality charts and graphs.
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.
Full – If done and supported by 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
6.6. Status reporting
Tool users need to status information in the requirements management tool.
Full – Using attributes.
6.6.1. Technical Performance Measurement status accounting
Status current technical performance of various allocated performance requirements and monitor progress towards goals.
Full – Using attributes.
6.6.2. Requirement progress/status reporting
Status reporting on current compliance/non-compliance to various requirements
Full – Using attributes.
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 – Using filtering and find capabilities.
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.
Partial – Through the use of MS NetMeeting documents can be reviewed and comments made using MS Word’s highlighting functionality. Actual requirements mak up can only take place if each team member has a copy of QSSrequireit installed locally on their PC.
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.
No compliance.
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?
No compliance – QSSrequireit does not support interfacing to other tools currently but it can certainly be accomplished by using DOORS.
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).
No compliance – Currently DOORS supports interfaces to over 28 tools in the marketplace.
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?
No compliance.
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 – Only those documents in MS Word’s 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?
No compliance – QSSrequireit is a stand-alone implementation based on MS Word.
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?
No complaince.
9.1. Single user/multiple concurrent users
Is the tool support a single user or multiple concurrent users?
Single User.
9.2. Multiple Platforms/Operating Systems?
Which platforms and operating systems does the tool run on?
Windows 95, 98 and Windows NT 4.0 or later.
9.3. Commercial vs. unique database
Does the tool use a proprietary or commercially available database?
No Compliance – QSSrequireit works entirely within MS Word. DOORS however, is built on top of a proprietary Object oriented database.
9.4. Resource requirements
Please identify hardware/software configuration requirements:
9.4.1 Memory requirements16MB memory for Windows 95
32MB memory for Windows 98 and NT 4.0
9.4.2. CPU requirements
Pentium II microprocessor
9.4.3. Disk space requirements
2MB for installation on top of MS Word
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?
No 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?
No compliance.
10.3. Interactive graphical input/control of data
Does the tool support graphical input and manipulation of data?
Partial Compliance – QSSrequireit does support graphical input but the data cannot be manipulated.
10.4. Which window’s standard do you follow?
If your tool supports a window’s standard, which one(s)?
MS Word 97 or later and VBA.
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?
Full – Users can indeed create scripts and record macros to automate their tasks.
10.6. Web browser interface
Does the tool allow a user to access the tool or database with a web browser?
No compliance.
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.
PartiaL Compliance – Only display/graphics.
12.1. Warrantee
Does your tool have a warrantee, if so what is it?
Full – QSSrequireit comes with a 30-day warranty for defective media.
12.2. Network license policy
Does the tool support network licensing (floating, node locked, etc.), if so which license manager?
Exclusively single node lock license.
12.3. Maintenance and upgrade policy
How often are software updates released; are updates separately priced items, etc.?
Software updates will occur every 6-9 months. All updates are available for purchase via the web site.
12.4. Online help
Are the users manuals online, is there online help with the tool?
Yes, there is complete online help available.
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 Uniform Resource Locator (URL)?
12.6. Phone support
What type of phone support is available from the tool supplier?
Hotline support 8am-8pm (EST) Monday – Friday.
13.4. Recommended training time
What is the recommended training time for a user to become proficient in using the tool?
Instantly as the tool operates entirely within MS Word and QSSrequireit provides templates as quick start capabilities. QSSrequireit also comes with a complimentary booklet, "Get it Right the First Time, Writing Better Requirements" which is used to educate basic users about writing quality requirements.
14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?
QSSrequireit provides entry-level capabilities for users with MS Word. An export to QSS’ DOORS provides full life cycle management capabilities of not only requirements but other information needed for accountability.
Contact Information
Name: Bill Colacurcio
Address: Quality Systems and Software
200 Valley Rd.
Mt. Arlington, NJ 07856
Phone: 201-770-6400
Fax: 201-770-6401
E-mail: bill_colacurcio@qssinc.com
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