INCOSE Requirements Management Tools Survey

INCOSE Tools Database WG - Requirements Mgmt. Tool Survey

Last Update: January 1998, Winter Business Meeting, Dallas

Tool Name: Tofs 98.1

Tofs (TOol For Systems), is a systems' engineering (modeling) toolkit, which includes support for requirements- management. Tofs runs in a PC under Microsoft Windows NT 4.0 together with Microsoft Word 97 (closely integrated)

Tool Version: 98.1

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.

1.1.1. Input document change/comparison analysis

The ability to compare/contrast two different versions of a source document

No compliance.

As Tofs is closely integrated with Microsoft Word 97, which has this capability, it is not included in Tofs.

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.

No compliance. However Microsoft Word's mechanism "Find" for key words and identifiers can be used to find requirements in a source 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?".

Partial compliance.

The human analyzer is expected to find, highlight and, when necessary edit the requirement in the source text to input it to Tofs through copy/paste.

1.4. Manual requirement identification

A manual means of identifying or creating requirements.

Full compliance.

Either through copy/paste from a source document or through manual (keyboard) input of a requirement directly into Tofs.

1.5. Batch mode operation

A mechanism for inputting/identifying requirements from outside of the tool.

Partial compliance.

Input of requirements from outside Tofs requires that the source document is in a form, which is readable by Microsoft Word 97.

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

No compliance.

Tofs presupposes that any update of numbered requirements is done in the numbered requirements' list within Tofs.

1.6. Requirement classification

Does the tool have the ability to classify/categorize requirements during identification

Full compliance

Tofs allows its user to set one or more attributes to each requirement. Attributes can be selected among predefined attributes or the tool user can define new 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.

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 compliance

Tofs allows its user to define a system a compositive object structure with objects depending on each other, with requirements as attributes to these objects. The structure is expressed as a set of object graphs (one for each structural level) and a tree graph (to give the complete structure).

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

The compositive object structure, used to model a system in Tofs is expressed textually (automatically) in the design language Odel (Object Design Language) combined with an object dependency tree, expressed textually.

3. Requirements flowdown

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.

Partial compliance

With Tofs each requirement is stand-alone, but requirements can be grouped and referenced to each other's through use of sub-headings, requirements' numbers and requirements' attributes. Derived requirements can always be introduced and distributed to design objects.

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

Each requirement can be linked to one or more of the objects in the system model. Allocation of portions of for example a weight requirement can be done through introduction (manually) of derived requirements to a requirement.

Note however that when you split a requirement into multiple sub-requirements the tool does not include any links between the requirements. To group requirements with Tofs you use numbering, sub-headings and comments.

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

As Tofs presupposes an object-oriented system view, you normally work from one design object. Tofs includes reqirements' allocation lists to also allow work from requirements' point of view.

Each design object is listed with its responsibility and fulfillment requirements.

Each requirement is listed with the objects that have the requirement as responsibility and fulfillment requirement.

The listings are based on the situation stored in the Tofs database.

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 as follows:

Rationale for a requirement can be included in a requirements' text as a comment.

Accountability is managed through distinction between responsibility and fulfillment requirements for each design object meaning:

A responsibility requirement is a requirement for which the current object or one of its support objects is responsible for fulfillment

A fulfillment requirement is a requirement which is to be tested with the current design object

Test/validation is managed through allocation of test cases as attributes to each design object and with use of requirements/test matrixes to connect requirements and test cases to each other, with manual verification that the test cases defined really cover (together) each requirement.

Criticality is managed as an attribute to requirements. It may be refined as for example safety, mission and environmental criticality.

Problem management in Tofs supports management of issues. Each issue is entered as a problem. A decided solution may often result in an update of one or more requirements.

4. Traceability analysis

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 compliance through listing of the requirements with the design objects to which they are allocated for responsibility and fulfillment.

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 compliance through a menu entry "View not fulfilled", which will show any requirement not allocated to a design object for fulfillment.

The tool does not stop its user from introduction of system elements without allocating any requirements, but such lack of requirements can be seen for each system element both from the tool's screen and from the documentation output from the tool.

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

For each design object, the allocated requirements can be shown, with their origin.

For each requirement can be shown which object(s) it is allocated to.

Note: as Tofs views requirements as attributes to design objects, the links in the tool are between design objects with their allocated requirements. Tofs does not support links between requirements in the current version.

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

Done through marking in the requirements/test matrix, with additional comments when necessary.

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).

Partial compliance

Done through marking in the requirements/test matrix, with additional comments when necessary. Actual results from testing and other verification must be input manually into the matrix.

The tool does not allow complete deletion of original requirements, why these are always present even if they are made invalid.

5. Configuration Management

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.

Partial compliance

Presupposed to be managed through manual insertion of dates, authority etc. as comments in the requirements' text on changes.

The tool does not allow complete deletion of original requirements, why these are always present even if they are made unvalid.

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.

Partial compliance as follows

Complete system models, including requirements and test specification can be saved away as baselines and then retrieved. Saving can also be done as read-only to avoid unauthorized changes.

Comparison between versions requires that you extract the document parts to be compared from different versions and use the comparison mechanisms in Microsoft Word 97.

5.3. Access control (modification, viewing, etc.)

The requirements should be able to be protected from modification, viewing, etc. by individuals or groups.

Partial compliance as follows

A complete system model, including its requirements can be stored as "integrated and approved". It can then only be changed through copying with a new identification.

You can also use the mode change mechanism for each design object and freeze an object as "frozen for review" or "frozen and completed".

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 compliance as follows:

As default a document can be produced by Tofs, which complies with MIL-STD-498 and IEEE/EIA 12207. The document structure can be tailored to comply with other standards, although newly introduced headings in the documentation will need to be filled in through Microsoft Word under Tofs.

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 as

Tofs is integrated with Microsoft Word 97 and uses its mechanisms for spell checking, etc

Tofs includes system consistency checks to show any inconsistencies between the different objects in a system model concerning interfaces between the different objects.

6.3. Presentation output

Once the information is loaded, the requirements' management tool should support the generation of presentation quality charts and graphs.

Partial compliance as Tofs is integrated with Microsoft Word 97 and can be further integrated with any Microsoft Office compliant graphic tool, the presentation quality will depend on the tool(s) selected for integration.

Note however that requirements are inserted solely as text, why diagrams, included in requirements, must be entered as "support graphs" with a reference from the requirement concerned.

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.

Partial compliance.

As Tofs is integrated with Microsoft Word and can be integrated with Microsoft Office-compatible diagramming tools such as for example Microsoft Excel or Microsoft PowerPoint, these tools define its ability in this respect.

Note however that requirements are inserted solely as text, why diagrams, included in requirements, must be entered as "support graphs" with a reference from the requirement concerned.

6.5. WYSIWYG previewing of finished output

The tool should allow the user to view the document on-screen in finished format.

Full compliance as each document is produced through Microsoft Word.

6.6. Status reporting

Tool users need to status information in the requirements management tool.

Full compliance as status and mode can be inserted and viewed for each design object in a system model.

Note however that this marking concerns the design objects and that no status marking is provided separately for requirements, unless entered as comments in requirement text.

6.6.1. Technical Performance Measurement status accounting

Status current technical performance of various allocated performance requirements and monitor progress towards goals.

Full compliance through:

Viewing detailed tested performance through the requirements/test matrix for each design object

Viewing coarse level performance as tested and approved objects are marked with status "tested and approved" in the configuration document.

6.6.2. Requirement progress/status reporting

Status reporting on current compliance/non-compliance to various requirements

Full compliance through:

Viewing detailed compliance tested through the requirements/test matrix for each design object

Viewing coarse level compliance as tested and approved objects are marked with status "tested and approved" in the configuration document.

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.

Partial compliance as follows:

With requirements' lists prepared for print through Microsoft Word, Word's Find command can be used

Within Tofs requirement's can be searched manually in overview lists with number and heading for each requirement

Within Tofs, requirements can be searched for each defined requirement attribute

Within Tofs requirements, with their allocation situation can be viewed for each design object.

7. Groupware

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 compliance as Tofs is delivered for use on one PC local network for each license (up to ten users per license). Each user has full availability to all information, although some caution is required when two users open the same Configuration Item.

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 as Tofs presupposes that access control is managed through splitting each system into a set of "Configuration Items", distributed to small groups with a responsibility for each group to control access within its area of responsibility (manually).

8. Interfaces to other tools

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?

The requirements' management part of Tofs receives input of requirements' information only through copy/paste and manual input. The requirements' management part of Tofs is fully integrated with other sub-tools within Tofs through the database.

Deeper integration with other tools will normally require OLE and or database programming, which must be considered for each case.

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 through Paradox database programming.

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?

The tool is based on Borland Database Engine and the Paradox database and thus has support for database standards like these have.

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?

No, input of requirements' information only through copy/paste and manual input.

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?

Information is exchanged on "Configuration Item" level through the commands "Save CI as" and "Add CI from". The CI information can then be transferred by storage media or over the Internet.

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, consistency checks are only supported within the same data set (Configuration Item). Exception: completed documents and partial documents can be compared through Microsoft Word.

9. System Environment

9.1. Single user/multiple concurrent users

Is the tool support a single user or multiple concurrent users?

Each Tofs is single user, but each Tofs license allows for ten users to work with separate copies of Tofs concurrently in a network. Each of these users are then expected to run a separate Configuration Item (to avoid confusion through possibly conflicting updates of one Configuration Item)

9.2. Multiple Platforms/Operating Systems?

Which platforms and operating systems does the tool run on?

PC running the Microsoft Windows NT 4.0.

9.3. Commercial vs. unique database

Does the tool use a proprietary or commercially available database?

The tool runs the Paradox, with the Borland database engine (commercially available, no separate license required for Tofs users)

9.4. Resource requirements

Please identify hardware/software configuration requirements:

PC running Microsoft Windows NT 4.0 (preferably in a local network as each Tofs license allows ten users)

Microsoft Word 97 (older Word versions do not work as Word is closely integrated with Tofs through OLE programming)

Memory requirements

At least 32 Mbytes of primary memory

CPU requirements

At least 100 MHz Pentium recommended, but will run also on slower CPUs.

Disk space requirements

About 5 Mbytes of hard disk space plus disk space for the system models, depending on their size.

10. User Interfaces

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?

Yes partially: while a report is built you cannot do anything else, but printing the report is done in background mode.

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?

Yes partially:

some views, which can be updated momentarily are updated automatically

some views, the update of which require time-consuming database operations, are updated only on request (update button).

10.3. Interactive graphical input/control of data

Does the tool support graphical input and manipulation of data?

10.4. Which window’s standard do you follow?

If your tool supports a window’s standard, which one(s)?

Windows NT 4.0

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?

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.

MIL-STD-498, supports production of documents to comply with this standard

IEEE/EIA 12207, supports work in accordance with the processes defined in the standard and production of documents to comply with the standard

ISO 9001, support work to comply with the standard

SEI CMM, level 3, the tools supports work to this level of the software engineering capability maturity model

SEI SE-CMM, level 3, the tool supports work to this level of the systems engineering capability model.

Ada 95, The Odel design language, supported by Tofs, complies with a simplified subset of the programming language.

Note that compliance with the standards in several cases, requires that that the tool is used as described in the method handbooks, delivered with the tool.

12. Support and maintenance

12.1. Warrantee

Does your tool have a warrantee, if so what is it?

90 days limited warranty that tool will function basically as described in the tool manual and with replacement of any defective data media.

12.2. Network license policy

Does the tool support network licensing (floating, node locked, etc.), if so which license manager?

The tool is only delivered as a network license for ten users on a local PC network ($ 3000). More than one network or more than ten users require an additional license. Floating a license in the meaning of moving it between different networks is allowed.

No hardware locking is required for the tool.

12.3. Maintenance and upgrade policy

How often are software updates released; are updates separately priced items, etc.?

Planned policy is:

at least one free update each year

separately priced updates each year with added functionality. Pricing will depend on the amount of new functionality.

12.4. Online help

Are the users manuals online, is there online help with the tool?

The tutorials in the user manuals are not online. There is extensive help online with the tool.

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)?

http://www.toolforsystems.com This URL includes download of an evaluation version of the tool (with full functionality)

12.6. Phone support

What type of phone support is available from the tool supplier?

Callback service after submission of a support question by e-mail.

13. Training

13.3. Recommended training time

What is the recommended training time for a user to become proficient in using the tool?

Tofs is delivered with two tutorials. Going through these tutorials should make a user sufficiently proficient to use the tool within three days. This is provided that the user knows and applies a systems engineering method, which complies with Tofs.

For those users who also want to learn a systems engineering method, six days is recommended: three to be spent on a training course and three to be spent on a trial project. Time to become proficient will also depend on previous experience.

14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?

As it is nowadays commonly understood that it is rarely possible to document all requirements prior to a systems' engineering effort and as testing tends to take a large amount of project time it is important that a systems engineering tool allows and supports its user to establish three concurrent processes:

A requirements' management process with possibility to update and add requirements

A system design process to design the system as a set of interacting objects

A test management process.

Tofs supports establishment of these three processes and also a problem management process as problems will surface in any non-trivial project and as orderly management of problem is necessary to complete the project on time and within budget.

All concepts in the original requirements should be formalized as types with parameters, messages and local data throughout the system referred to these types. Tofs supports such management.

Requirements concerning criticality require formal system descriptions and facilities to analyze system dependability from a model. This is supported by Tofs.

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