INCOSE Requirements Management Tools Survey
CORE Enterprise 4.0
Key to Systems Engineering Success
CORE supports a formal, integrated approach to concurrent systems engineering activities that encompasses top-down, middle-out, and bottom-up (reverse) engineering. A key consideration in the CORE approach is that all steps employ a centralized system description repository which ensures a common, controllable baseline. With the release of CORE Enterprise 4.0, multiple concurrent users with simultaneous access is supported.
CORE enables the user to extract the originating requirements from their source documentation, analyze them for completeness, consistency and testability, and trace each requirement to a behavioral model which describes the interactions and process sequences. The system behavior is represented by user-selectable graphical views which capture the system control logic and data flow in an integrated manner. The user allocates the system functional models to a physical system architecture. Verification and validation facilities are available in CORE to execute and test these models to establish system performance and resource usage.
CORE supports a diversity of challenging applications:
Outline
1. Capturing Requirements/identification
Using existing document information (such as
glossary, index, etc.), aid the user in requirements analysis, identification
of requirements, etc.
FULL COMPLIANCE
1.1.1. Input document change/comparison analysis
The ability to compare/contrast two different
versions of a source document.
FULL COMPLIANCE
A mechanism for automatic identification of
requirements by key words, structure, unique identifiers, etc. to create
requirements from the text.
FULL COMPLIANCE
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
1.4. Manual requirement identification
A mechanism for inputting/identifying requirements
from outside of the tool.
FULL COMPLIANCE
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
Does the tool have the ability to classify/categorize
requirements during identification
FULL COMPLIANCE
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.
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
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
Once the requirements have been captured and system architecture captured, requirements are allocated to the various system elements.
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
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
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
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 through
ERA database
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.
The tool should allow the user
to identify inconsistencies such as unlinked requirements or system elements
(orphans).
FULL COMPLIANCE
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
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
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 COMPLIANCE
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
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 COMPLIANCE
5.3. Access control (modification, viewing, etc.)
The requirements should be
able to be protected from modification, viewing, etc. by individuals or
groups.
FULL COMPLIANCE
The requirements management
tool should output documentation in various military/commercial standard
formats (490, 2167, etc.).
490, 498, 632, 2167
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
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
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
6.5. WYSIWYG previewing of finished output
The tool should allow the user
to view the document on-screen in finished format.
FULL COMPLIANCE
6.6. Status reporting
Tool users need to status information in the requirements management tool.
Status current technical performance
of various allocated performance requirements and monitor progress towards
goals.
FULL COMPLIANCE
6.6.2. Requirement progress/status reporting
Status reporting on current
compliance/non-compliance to various requirements
FULL 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
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.
The tool should support a team
of engineers reviewing, marking up, and commenting on requirements or implementation
alternatives.
FULL COMPLIANCE
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.
FULL COMPLIANCE
Requirements management must have the ability to communicate requirements to other domain-specific design tools (CASE, EE, etc.).
What tools will your requirements
management tool interface with or talk to?
DOORS, RDD-100, Vital Link,
Software thru Pictures, Rational Rose, MS Office (Word, Excel, Power Point)
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
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?
PARTIAL COMPLIANCE, via
simple query language.
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 COMPLIANCE
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
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 COMPLIANCE
Please identify hardware/software configuration requirements:
9.4.2. CPU requirements
Pentium, 300 Mhz
or better
9.4.3. Disk space requirements
80 MB (includes documentation
and on-line help files)
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?
FULL COMPLIANCE
10.3. Interactive graphical input/control of data
Does the tool support graphical
input and manipulation of data?
FULL COMPLIANCE
10.4. Which window's standard do you follow?
If your tool supports a window's
standard, which one(s)?
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?
FULL COMPLIANCE
Which military/commercial standards
does your tool comply with--including database standards, output document
standards, exchange standards, display/graphics standards, etc.
490, 498, 499, 632, 2167
Does your tool have a warrantee,
if so what is it?
90 days. Maintenance plan
includes upgrades.
12.2. Network license policy
Does the tool support network
licensing (floating, node locked, etc.), if so which license manager?
FULL COMPLIANCE, proprietary
license manager, all supported.
12.3. maintenance and upgrade policy
How often are software updates
released; are updates separately priced items, etc.?
Two major releases per
year, point upgrades often. All releases and upgrades included in maintenance.
12.4. on-line help
Are the users manuals on-line,
is there on-line help with the tool?
FULL COMPLIANCE
12.5. Internet access/Mosaic home page location
Does the tool supplier have
an Internet address or Mosaic home page location?
FULL COMPLIANCE,
e-mail: info@vtcorp.com
Web: http://www.vitechcorp.com
12.6. phone support
13.3. Recommended training time
What is the recommended
training time for a user to become proficient in using the tool?
1-3 days
14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?
The system’s component parts,
with allocated behavior, defined interfaces, traceability to requirements
and design rationale makes up the physical architecture.
FULL COMPLIANCE
13.2 Physical architecture must be executable to perform dynamic analyses.
The behavior models allocated
to the component parts of the physical architecture are executed in a discrete-event
simulation framework.
FULL COMPLIANCE with CORESim
Contact Information
Company: Vitech Corporation
Address: 2070 Chain
Bridge Road
Suite 100
Vienna, VA 22182
Contact: Vitech Corporation
Phone: 703-883-2270
FAX: 703-883-1860
E-mail: info@vitechcorp.com
Web: http://www.vitechcorp.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