INCOSE Requirements Management Tools Survey
EDS SLATE Response
SLATE 6.1
Outline
- Capturing Requirements/identification
- Capturing system element structure
- Requirements flowdown
- Traceability analysis
- Configuration Management
- Documents and other output media
- Groupware
- Interfaces to other tools
- System Environment
- User Interfaces
- Standards--which ones do you comply with?
- Support and maintenance
- Training
- What other requirements management features do you as a tool supplier
think are important (modeling, etc.)?
1. Capturing Requirements/identification
- 1.1. Input document enrichment/analysis
(partial compliance)
The intent of this requirement to extract links, etc. from information already existing
in the input document. Frame and Word are integrated with SLATE and have some capabilities
to automatically generate indexes, Table of Contents, etc. from the structure of a
document, but has no capabilities to extract information such as links. As such, SLATE
does not have the capability to extract information from Table of Contents, Index's, etc.
to help identify requirements. SLATE does understand document structure and will create
equivalent paragraphs, titles, etc. inside of SLATE as in the original document--once
loaded, documents can be parsed for requirements based on the structure of the document.
In addition, SLATE can extract traceability information from embedded links (i.e. [SSS
3.2.1]) if needed.
1.1.1. Input document change/comparison analysis
(full compliance)
Because SLATE is integrated and delivered with Framemaker and Word, SLATE can utilize
Framemaker's and Word's document change/comparison capability.
1.2. Automatic parsing of requirements
(full compliance)
SLATE includes several requirement parsers; 1) structure parser (requirements built
based input document structuree--i.e. a new requirement for each sentence); 2) key word
parsing (requirement generated each time it see's a shall), and 3) a regular expression
searching/parsing capability to help identify requirements out of source text documents
based upon boolean expressions (i.e. this but not that).
1.3. Interactive/semi-automatic requirement identification
(partial compliance)
SLATE's report generator can be used to help identify requirements by searching text
strings which can then be "symbolically referenced " in an interactive mode.
SLATE does allow the user to write their own parser using industry standard Tcl (Tool
Command Language) which could include an interactive means (mouse highlighting) of
identifying requirements.
1.4. Manual requirement identification
(full compliance)
SLATE enables the user to manually create or identify requirements.
1.5. Batch mode operation
(full compliance)
The intent here is to be able load requirements and links from outside of the tool (such
as an ASCII text file with embedded ROI numbers/links). SLATE allows the user to design
their own "requirement parser" which can be used to parse requirements from an
external file. In addition SLATE support OLE automation which would allow external tools
to "batch update" SLATE information.
1.5.1. Batch-mode document/source-link update
(partial compliance)
SLATE 4.2 via FrameMaker does include a document compare and update feature--allowing
the user to identify changes. Several Tcl commands are included that allow the user to
copy/move links once the updated document paragraphs are identified.
1.6. Requirement classification
(full compliance)
Requirement attributes can be set to classify/categorize requirements during the
requirements parsing process. Requirement attributes can also be set via the report
generator that allows the SLATE user to organize information by keywords, linkages,
family, etc.
In addition to attributes, SLATE provides other means of categorizing or
classifying requirements, including:
Organize requirements by folders (folders of performance requirements for example)
Organize them by sub-types (requirements of type performance)
Organize them by groups (SLATE includes a group object which allows the user to
virtually organize any object in the database including requirements--for example, these
requirements are assigned to this team)
Organize them by what they are linked/allocated to (show me all requirement defining
this element)
2. Capturing system element structure
- (full compliance)
- SLATE has the ability to build "hierarchies" of system elements. There can be
many of these hierarchies each representing a different perspective on the design
problem--physical, functional, WBS, project personnel, maintenance, etc. SLATE also has
the patented ability to inter-relate elements of the various hierarchies such that a
change in one can be seen in the other hierarchies (for example a change in personnel
impact on the WBS or Test aspect of the system).
-
- 2.1. Graphically capture systems structure
- (full compliance)
- SLATE captures and displays all system elements graphically--either in an outline, tree,
or functional view. Hierarchies can be created and manipulated using the mouse to drag and
drop sub-system elements.
-
- 2.2. Textural capture of systems structure
- (full compliance)
- SLATE can also display system elements in an outline or textual view and
link requirements to those sub-system elements.
-
3. Requirements flowdown
- (full compliance)
- SLATE allows the user to link requirements to various system sub-elements. There is also
the idea of inheritance. For example, linking a requirement to the top of a functional
hierarchy means that all of the children functions inherit that requirement (unless
explicitly blocked for flowing downhill).
-
- 3.1. Requirements derivation (req. to req., req. to analysis/text)
- (full compliance)
- SLATE allows the user to derive requirements from other requirements and link derived
requirements to their source. Requirements can also be linked to documents or document
paragraphs representing trade studies; which in turn can be linked to other derived
requirements.
-
- 3.2. Allocation of performance requirements to system elements
- (full compliance)
- SLATE allows technical budgets (power, weight, cost, etc.) to be attached to system
implementation hierarchies (requirements can also be linked to budgets). Technical budgets
allow the user to allocate portions of a performance requirement to various system
elements and track compliance with the performance requirement. "Watch Dogs" can
be set to monitor compliance and react if required value is violated (i.e. email, set
flags, etc.).
-
- 3.3. Bi-directional requirement linking to system elements
- (full compliance)
- Links are objects in SLATE. As such, SLATE allows requirements to be linked to any other
system element. Once linked, the link can be viewed from either the complying or defining
side (i.e. bi-directional). Requirements and system elements are linked by dragging and
dropping one on the other.
-
- 3.4. Capture of allocation rationale, accountability, test/validation, criticality,
issues, etc.--if so how and what mechanism does it use?
- (full compliance)
- SLATE supports the capture allocation rationale, accountability, etc. by allowing the
user to attach notes to any object in the SLATE database. The notes can be
classified/categorized by setting attributes or sub-typed (notes of type rationale). The
notes feature effectively creates an engineering project notebook capability allowing the
project users to capture all relevant information. In addition, behavior can be associated
with the objects such as a requirement management process that is triggered when a
requirement is modified.
-
4. Traceability analysis
- (full compliance)
- Once the links are in place, SLATE allows the user to view the links or "run"
the links using the report generator and output the results in the user's choice of
formats (trace tables, design specs, etc.). Using SLATE's reference feature the trace
tables and documents update automatically as the requirements and allocations change.
-
- 4.1. Identify inconsistencies (orphans,...if so what kind of...)
- (full compliance)
- The SLATE report generation facility includes the ability to identify requirements (or
other objects) without complying or defining objects. In addition, because the report view
is live, objects can be manipulated directly in the report window.
-
- 4.2. Visibility into existing links from source to implementation--i.e. follow the
links.
- (full compliance)
- The user can follow the links interactively or via the report generator to get the
visibility needed.
-
- 4.3. Verification of requirement (was it done, how was done)
- (full compliance)
- Notes and attributes can be used to verify that requirements have been met. In addition,
verification status can be monitored by the system to automatically trigger events based
on the state of the database. For example, if a requirement has changed or failed a test,
project personnel could be notified via email.
-
- 4.4. Requirement performance verification from system elements (roll up of actuals)
- (full compliance)
- Technical budgets can be both allocated and rolled up to support requirement
verification. As budget actuals get rolled up, SLATE generates a report of variances
showing budget variances. Budget values (allocated and actuals) can also be accessed from
the report generation facility. Additionally, "watch dogs" can be set to go off
when values exceed user specified thresholds.
-
5. Configuration Management
- 5.1. History of requirement changes, who, what, when, where, why, how.
(full compliance)
SLATE automatically tracks who changed what when and can force a why. In addition,
History Objects are created and attached to the changed objects. The user can set the
"History Policy" that controls what level of detail history that gets maintained
(recording a link to an object, maintain a detailed before and after history of each
object, etc.). SLATE also supports enforcing a CM process--forcing the user to follow a
specific release or change process.
5.2. Baseline/Version control
(full compliance)
SLATE allows the user to baseline all the objects in the database. The Group command
allows the user to identify all objects that are in particular release. However, the
current release does not support "revert" to prior release command (i.e. return
the database to how it was on June 1, 1999--although the report writer can show all
objects that have changed since a given date).
5.3. Access control (modification, viewing, etc.)
(full compliance)
SLATE controls access at the database and object level (read/write/modify) by individual
or user group. SLATE objects include things like requirements, attributes, links, document
paragraphs, etc.--allowing you to control access at the document paragraph or individual
requirement level if needed.
6. Documents and other output media
- 6.1. Standard specification output (if so what kind)
(full compliance)
SLATE uses Framemaker or Word as its document generation engine (Framemaker and Word are
integrated with SLATE). Standard Frame and Word templates are available for nearly all
military and commercial standard output formats including 490, 2167, etc.
6.2. Quality and consistency checking (spell, data dictionary)
(full compliance)
SLATE includes a spell checker.
6.3. Presentation output
(partial compliance)
SLATE supports easy presentation output through the use of its report generator and the
ability to format the results of the report generator into nearly any user defined format.
In addition, SLATE 4.x supports OLE connections to presentation tools such as MS
Powerpoint.
6.4. Custom output features and markings (user definable tables, figures, security
markings..)
(full compliance)
SLATE was built to output documents in finished format including security markings
(derived from attribute settings), graphics, tables, etc. SLATE also has graphic and table
objects which can be automatically updated and exportable into the finished documents (for
example, trace matrices are automatically updated as links are created, when exported or
included in a document, the trace matrix is also up to date).
6.5. WYSIWYG previewing of finished output
(full compliance)
WYSIWYG previewing is provided by Framemaker or Word which are integrated with SLATE.
6.6. Status reporting
(full compliance)
SLATE comes with a flexible report generation facility that allows the user to status
database information (i.e. show all requirements that have yet to be tested). SLATE also
comes with a number of predefined reports that can be used as starting points for custom
queries. Reports can also be triggered on a clock (run a status report every night at
midnight) or event (such as logging into the system). Because the windows generated by the
reports are "active"--the user can work directly in the report windows.
6.6.1. Technical Performance Measurement status accounting
(full compliance)
Technical budgets can be baselined and monitored for progress towards predefined goals.
"Watch Dogs" can be set to go off at specific TPM performance thresholds. In
addition, SLATE allows the user to see via it's patented TRAM feature which items are the
greatest contributors to achieving/not-achieving TPM goals.
6.6.2. Requirement progress/status reporting
(full compliance)
SLATE's report generator allows the user to monitor requirement compliance or
non-compliance by statusing requirement attributes. Reports can also be triggered by
events or on a timed basis to automatically generate status reports.
6.6.3. Other ad hoc queries and searches
(full compliance)
SLATE's report generator allows the user to form ad hoc query's and searches on any
object or relationship in the database.
7. Groupware
- (full compliance)
- SLATE is built on top of a commercial multi-user Object Oriented database (Versant)
which allows many people to be working on the same database at the same time--even
geographically dispersed teams.
-
- 7.1. Support of concurrent review, markup, and comment
- (full compliance)
- SLATE supports concurrent review, markup, and comment through its notes facility. Notes
can be attached to any database object and its attributes set to comment, review, sign
off, etc. (the attribute choices and types are user definable). In addition, requirements,
notes, document paragraphs, etc. can be forced to follow a review process which shepards
them through a standard process (i.e. no requirements get changed in the database until
approved).
-
- 7.2. Multi-level assignment/access control
- (full compliance)
- SLATE controls access at the database and object level. SLATE can also enforce a process
by associating behavior with objects (for example, you can trigger the requirement
management process when a requirement is changed). The report generator can also be used
to monitor changes in objects.
8. Interfaces to other tools
- 8.1. Inter-tool communications
SLATE was built on an open-architected OODB with the idea being that it would act as the
"information integrator" for many different tools. The exchange of information
can take place through several means:
External Symbolic reference (the ability to directly reference information that is
outside of SLATE via file references)
Database-to-Database maps provided by Versant
SQL/OQL query's
ASCII import/export in standard STEP format
API programmable interface
DCOM/OLE
Emerging database exchange standards such as ODBC and CORBA
8.1.1. Interfaces to other tools ________?
CASE tool interfaces--bi-directional interface to CASE environments such as Rational
ROSE, GD-Pro, Teamwork, StP, COOL:Jex (aka ObjectTeam), ObjectTime, and others SA and OO
analysis tools such that links from SLATE can be attached to CASE tool objects (allowing
flowdown to the code module level)
Simulation tool interfaces such as MatLab/Simulink allowing you to drive simulations
from SLATE
Metrics monitoring Tools--such as MetricCenter, spreadsheets, etc.
PDM management tools like Metaphase
OLE compliant tools such as office suites (allowing Excel Spreadsheets to modify SLATE
information)
…SLATE also allows you to drive tools that support a command line interface--that
is if a tool has a command line interface, SLATE can talk to it.
8.1.2. External Applications Program Interface available
(Full compliance)
The SLATE API uses the Tcl (pronounced tickle) open industry standard as its API
communication language. A graphical component of Tcl, Tk can also be used to build your
own applications that use SLATE information. In addition, SLATE also supports OLE, STEP
format import/export, ASCII file import/export, SQL, and CORBA standards to exchange
information.
8.1.3. Support Open database system (standard query access)
(full compliance)
SQL and the emerging OQL standard query languages/tools are available for our Versant
database.
8.1.4. Import of existing data from various standard file formats?
(full compliance)
SLATE has the ability to import existing data to create internal link structures through
import/export of STEP standard format files. Other file formats can be used and imported
by using SLATE's customizable Tcl import feature.
8.2. Intra-tool communications
8.2.1. Exchange of information between same-tool different installations
(full compliance)
Since SLATE is built on a true distributed multi-user client-server database, SLATE
installations at widely diverse geographic locations can access the same database at the
same time through world-wide LAN connections. SLATE also supports "long
transactions" which allows a part of the database to be separated from the parent
database and automatically resynchronize upon return.
8.2.2. Consistency/comparison checking between same-tool datasets
(partial compliance)
The SLATE report generation facility can produce reports on all database objects
allowing the user to look at the differences between two databases--but there is no single
facility for comparing and contrasting two different SLATE databases.
9. System Environment
- 9.1. Single user/multiple concurrent users
Multiple concurrent users
9.2. Multiple Platforms/Operating Systems?
Win95/98, Windows NT, SUN Solaris, HPUX all can share the same database across
platforms.
9.3. Commercial vs. unique database
SLATE is built on top of the Versant commercially available OODB.
9.4. Resource requirements
9.4.1. Memory requirements
Project SLATE server requires 96 meg.
Client Workstations require 32 meg.
9.4.2. CPU requirements
Win95/98, NT PC, HP, or SUN
9.4.3. Disk space requirements
Project SLATE server 1.0 gig. of disk space recommended
Client Workstations require ~40 meg.
10. User Interfaces
- 10.1. Doing one thing while you are looking at another
(full compliance)
SLATE's multiuser database allows the user to be doing many different things in the
database at the same time.
10.2. Simultaneous update of open views
(full compliance)
SLATE takes care of updating all affected views/windows--i.e. a change in one view is
automatically reflected in all other views. Other team members working on the database
will also see changes to their views of the database through the "refresh"
database command--SLATE guarantees that the user is always looking at current information.
10.3. Interactive graphical input/control of data
(full compliance)
SLATE uses the mouse to support graphical input and manipulation of data.
10.4. Which windows standard do you follow?
MS Windows, Motif, Openwindows, TWM, X-windows--in addition SLATE can switch "look
and feel" on startup with a switch such as SLATE -windows would start up SLATE in a
MS Windows "look and feel".
10.5. Executable via scripts (recordable) or macros
(full compliance)
SLATE uses the standard Tcl (pronounced tickle) command language as its scripting/macro
language.
11. Standards--which ones do you comply with?
- Display standards: MS Windows, OSF/Motif, Openwindows
- Military/Commercial SE standards that SLATE supports: IS09000, 499a/b, 490, 2167,
IEEE-632, EIA 731
- Database standards: SQL, OQL, CORBA
-
12. Support and maintenance
- 12.1. Warranty
SLATE's warranty includes:
the software when delivered and properly installed will function as specified
documentation provided will be sufficient to allow the customer to use the product
effectively the media on which the software is delivered will be free from defects.
12.2. Network license policy
SLATE is a network licensed tool that can be made to float or be node locked. SLATE uses
the FlexLM license manager.
12.3. Maintenance and upgrade policy
There is a SLATE release twice per year. All updates and enhancements are included in
the maintenance price.
12.4. Online help
SLATE manuals are delivered online and hyperlinked. Online help in the tool is the same
as the printed material.
12.5. Internet Web page location
SLATE maintains a home page at: http://www.eds.com/products/plm/slate
SLATE can also be accessed via the web through its tranSLATE family http://www.xslate.com
EDS SLATE support can also be reached at: info@slate.sdrc.com
or support@slate.sdrc.com
12.6. Phone support
EDS Maintains a customer support hotline
13. Training
- 13.3. Recommended training time
- SLATE Basic training is three days.
- SLATE System Administration training (for database management) is 1/2 day.
14. What other requirements management features do you as a tool
supplier think are important (modeling, etc.)?
- Another important aspect of Requirements Management is the ability to bring all the
relevant requirements to bear on the problem--including reliability, maintenance,
logistics, cost, etc.--much more than just the customers technical requirements. SLATE
allows the engineer to consider these many different perspectives into the design problem
by allowing the engineer to capture and relate these requirements from their different
perspective.
-
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