Last Survey Update: January 1998, January Business Meeting, Dallas
Tool Name: Systems Engineer
Response Date: January 2000
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.
Ans: None. Systems Engineer is a minimal
tool, and does not inclued document parsers or text processors
1.1.1. Input document change/comparison analysis
The ability to compare/contrast two different versions of a source document
Ans: None
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.
Ans: None
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?".
Ans: None
1.4. Manual requirement identification
A manual means of identifying or creating requirements.
Ans: Partial. You can import requirements from various rtf or
.xls formats.
1.5. Batch mode operation
A mechanism for inputing/identifying requirements from outside of the tool.
Ans: None
1.6. Requirement classification
Does the tool have the ability to classify/categorize requirements during identification.
Ans: Full. The tool has several different
mechanisms for classifying requirements, including assignment to subsystem, hierarchical
placement in the derivation of the requirements tree, and allocation to a particular
component or functional module.
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.
Ans: None.
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.
Ans: Full
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.
Ans: Full. The tool provides flexible requirement derivation
linkage, including multiple inheritance and arbitrary hierarchy depth.
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.
Ans: Full. System elements can be described in terms of
integrated components of particular configuration (...a "release") or the
individual components can be separately attached to one or more requirements.
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.
Ans: None.
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.
Ans: Full. Requirements contain multiple linked elements,
including source documents & references therein (such as customer requiremens
docs) target documents (as in vendor component specifications), rationale, status,
progress notes, validation status and method, and the system element and version thereof
to which a requirement is linked.
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).
Ans: Full. Orphans are identified when created, frequently searched
for, and easily identifiable.
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
Ans: Full. The tool provides very easy graphical point and click
browsing of the reuirements linkage, both up and down, as well as arbitrary traverse of
the entire database.
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.
Ans: 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).
Ans: Partial The tool allows verification method assignment
and tracks linkage from testing, to test results, to bugs, to the version tested. Where
testing is not required, the verification status (eg demonstrated, inspected, reviewed,
cancelled...) is manually set. This state is maintained for each requirement.
Ans: Partial. The tool records the date of most recent change to requirements and status. It tracks test results against the version of each component. History of changes is not otherwise documented unless incremental archives are made.
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.
Ans: None.
5.3. Access control (modification, viewing, etc.)
The requirements should be able to be protected from modification, viewing, etc. by
individuals or groups.
Ans: Full. Access control is implemented in the database tool
(Microsoft Access).
6. Documents and other output media
6.1. Standard specification output (if so what kind)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.
Ans: Partial. Spell checking is possible.
6.3. Presentation output
Once the information is loaded, the requirements management tool should support the
generation of presentation quality charts and graphs.
Ans: None.
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.
Ans: Partial
6.5. WYSIWYG previewing of finished output
The tool should allow the user to view the document on-screen in finished format.
Ans: Full.
6.6. Status reporting
Tool users need to status information in the requirements management tool.
Ans: Partial
6.6.1. Technical Performance Measurement status accounting
Status current technical performance of various allocated performance requirements and
monitor progress towards goals.
Ans: Partial
6.6.2. Requirement progress/status reporting
Status reporting on current compliance/non-compliance to various requirements
Ans: 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.
Ans: Full.
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.
Ans: None.
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.
Ans: Partial.
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?
Ans: None.
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).
Ans: None
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?
Ans: Full, ODBC.
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?
Ans: Partial. Microsoft access imports .xls, .doc and .rtf
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?
Ans: None8.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?
Ans: None
9.1. Single user/multiple concurrent users
Is the tool support a single user or multiple concurrent users?
Ans: Multiple concurrent users.
9.2. Multiple Platforms/Operating Systems?
Which platforms and operating systems does the tool run on?
Ans: Windows.
9.3. Commercial vs. unique database
Does the tool use a proprietary or commercially available database?
Ans: MS Access
9.4. Resource requirements
Please identify hardware/software configuration requirements:
Ans: Vanilla Pentium class system.
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?
Ans: 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?
Ans: Full.
10.3. Interactive graphical input/control of data
Does the tool support graphical input and manipulation of data?
Ans: None.
10.4. Which window’s standard do you follow?
If your tool supports a window’s standard, which one(s)?
Ans: 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?
Ans: Partial. This is possible through Microsoft macros, but not
very useful.
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.
Ans: None.
12.1. Warrantee
Does your tool have a warrantee, if so what is it?
Ans: Refund if unsatisfied.
12.2. Network license policy
Does the tool support network licensing (floating, node locked, etc.), if so which
license manager?
Ans: No. A single copy can support a small team of networked users:
there is no license locking.
12.3. Maintenance and upgrade policy
How often are software updates released; are updates separately priced items, etc.?
Ans: Updates are offered free via internet download. Upgrades are
offered at reduced price for registered users.
12.4. Online help
Are the users manuals online, is there online help with the tool?
Ans: Help and examples are built into the tool. Move your mouse, and
advice pops up. A simple example project "lives" in the database alongside
yours, providing structural and use examples.
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)?
Ans: http://www.bluespruce.net/bluespruce
.
12.6. Phone support
What type of phone support is available from the tool supplier?
Ans: Call (303)579-8071 for assistance.
13.3. Recommended training time
What is the recommended training time for a user to become proficient in using the
tool?
Ans: Users can become proficient in most operations in one day. This
was an important design goal for the tool.
14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?
Ans: The tool includes tests, test event logs (particular executions of each test) bugs and configurations, not just requirements. Links between each of these are tracked as you would expect. Also, this tool is inexpensive.
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