INCOSE Tools Database Working Group

Requirements Mgmt. Tool Survey

Last Updated: January 2000 January Business Meeting, Mesa AZ

 

Please identify which version number (1.0, 3.5 etc.) of the tool this survey refers to.  Please respond to each question with a Full, Partial or No Compliance answer.  Additional text may be included for further explanation.

 

New or revised questions for 2001 are highlighted.

 

Previous responses and summaries can be located at the INCOSE Web site at URL www.incose.org/tools 

Tool Name: C.A.R.E. (Computer Aided Requirements Engineering)

Tool Version: 3.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 COMPLIANCE

Existing documentation can be introduced in various ways into SOPHIST’s RM tool C.A.R.E. Furthermore, CARE supports risk management allowing “tunable” project handling from light to heavyweight. CARE supports extreme requirements management (eXtremeRM) on the light end of the scale, to the RUP for the middle or all the way  to our military and government-project oriented process Object Engineering®, as well as your own custom-made process. Both eXtremeRM and OE are the result of  industry-proven, large-scale world-wide distributed software development that includes glossary, requirement templates, use case specification (high level and extended), acceptance criteria (test plan), linguistic methods, analysis model, simulation model, workflow definitions, and ISO 9000.

1.1.1    Input document change/comparison analysis

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

 

FULL COMPLIANCE

Different input documents may be compared for their corresponding requirements and identification via import, baselining and export.

 

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 COMPLIANCE

General import parsing, template input parsing, structural identifiers identification of requirements and related information. Excel spreadsheets may also be structurally parsed for import.

 

 

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

In addition to automatic import strategies, requirements may also be interactively isolated for unique identification by CARE.

1.4.            Manual requirement identification

A manual means of identifying or creating requirements.

 

FULL COMPLIANCE

From imported documents, a single requirement may be uniquely identified by the user. Manual creation of requirements is, of course, also supported.

1.5.      Batch mode operation

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

 

FULL COMPLIANCE

Entire word documents and excel spreadsheets may be marked marked for precise organization in the requirements hierarchy upon batch mode import as well as direct API support for importing requirements via COM or CORBA interfaces..

 

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.

External documents and CARE are linked with a unique requirement number.  From either word or excel, import updates will retain the structure of the original document. Changes to the original document can be reflected in CARE on import without any linking. Baselines can also be made of each version which allow for easy change recognition and acceptance. Additionally, CARE has a work environment that supports full editing, workflow, baselining and report statistics such that further batch updates should not be necessary.

1.6.            Requirement classification

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

FULL COMPLIANCE

Classification, categorization and identification of all requirements and their associated information may be organized by standard hierarchies or any form of user-defined classification system. This includes but is not limited to any sub-set of the following: Attribute(s), Service(s), Relation(s), Author, Change Request, Chapter, Class, Classification, Cost, Criticality, Delivery, Document Release (i.e., version), Miscellaneous, Model Consistency, Primary Reference, Prototype Build, Prototype Consistency, Requirement, Requirement Number (linear or hierarchical), Scope, Secondary Reference, Short Description, Short Description Number, Site, Specification Level, State, Sub-system, System Release, Version; Workflow.

 

 

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

However the user chooses to organize the requirements, such as functional decomposition, can be reflected graphically with various views allowing the requirements to be graphically associated with that particular view of the system.  Graphical charts (bar, pie, interpolated line) depict project and sub-project allocation and/or progress. Separation of requirements into user-defined categories or default structuring such as analysis, definition, overview, or design oriented categories such as PDC, HIC or DMC. Requirements may also be linked to use cases. Raw data may also be organized hierarchically as in a tree structure, or linearly.

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

Requirements presentation can be primarily textual and various system requirement groupings can be made according to how each requirement is classified or written. One requirement may have multiple categories attached  depending on the phase it particularly concerns, the part of the system it concerns or some other user-defined classification scheme. This is furthered with workflow concepts, as well as hierarchical, tree-based and plain document access.

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.

 

FULL COMPLIANCE

Derivation of a requirement is a core feature and is supported with automatic versioning as well as time/date stamping for traceability analysis and classification according to the type of connection being made. Branching possibilities exist for multiple requirement derivations. URL links can be made from any requirement to another requirement, supporting material or to wherever one pleases and is a very flexible and general solution for special cases not handled more directly elsewhere.

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

For each requirement, zero or more possible allocations may be assigned according to cost, criticality (risk), scope, workflow, earned value (weight) and numerous other user-defined or built-in allocation categories.

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

All links are bi-directional and their creation may begin with either the requirement(s) or the system element(s).

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

 

Purpose/reasons for a requirement are primary for all requirements. Starting with interviews of stakeholders, requirements are derived and assigned a workflow. Workflow insures that the requirement goes through a critical assessment by the customer, domain experts and requirements engineers. All requirements have an associated history, both in branching structure and related acceptance criteria as well as reason for the branch or test criteria. Each assignment or change to a requirement or its associated allocation parameters can also be automatically challenged by the system requiring a reason from the person making the change. This then also becomes a part of the history of the requirement in a hierarchical fashion.

 

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.

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

Identification of orphaned requirements/system elements is possible and strongly recommended via an automatic process (agent). Identification of inconsistencies is also possible via graphical inspection or manual review of the individual requirements or system element if one so desires.

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

Any link may be followed from requirement, through all branches, forwards and backwards and on to whatever system element it is assigned to in the software model, prototype or implementation.

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

This is fundamental to the workflow of each requirement. The last person to sign the requirement can only do so after the requirement’s test criteria has been completely specified. Upon product acceptance, the test criteria must all be fulfilled as per the requirements specification which also serves as a legal and binding document.

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

All test criteria for each requirement must be signed-off by the customer. The customer may grant variances. “Planned” versus “actual” values can be recorded and compared. Discrepancies between values can also be listed in reports.

 

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.

 

FULL COMPLIANCE

This is fully supported with our tool and is closely related to the requirement derivation features. The tool asks the reason for the derivation, and automatically assigns who and when. All users with this authority are logged into the system and therefore uniquely identifiable. If this were not the case, the derivation or change would not be possible.

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

Baselining requirements at multiple project stages are possible (and strongly recommended) via agents that can be manually or automatically scheduled. Differencing between the various baselines is also supported.

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

User permissions are highly configurable according to the current (and changing) needs of a project. System access permissions for read, comment, read-write are standard. The various user access configurations are extensive. Fundamental to CARE’s structure, read and write permissions are carefully controlled with a version control system to insure data integrity

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 (MIL-STD-490, DoD-2167A, etc.).

 

FULL COMPLIANCE

CARE supports several standard formats and word templates may be created that conform to any standard desired.

6.2.            Quality and consistency checking (spell, data dictionary,etc.)

The tool should also support document quality and consistency checking through spell checking, data dictionaries, acronym tables, etc.

 

FULL COMPLIANCE

Built in spell checking and dictionaries support quality and consistency at a fine level. Entire requirements can be checked against requirement templates for syntactic correctness and style as well as proper process word selection. System-specific term glossary and acronym tables as well as spell checking supports correctness of the requirements on a syntactic level. Requirement templates insure overall readability and quality and enable automated semantic checking and semi-automatic translation into OO models.

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

Management overview charts {pie, bar, line} can be generated according to system, time, requirement classification, status of project, sub-project and combinations thereof. If necessary, exporting information to Excel is possible for further charting needs with external data.

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

All user input, diagrams, markings, url links may be output as seen on-screen. If necessary, all information in the system can be exported to Rich Text Format or directly to Word or Excel.

6.5.            WYSIWYG previewing of finished output

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

 

FULL COMPLIANCE

WYSIWYG is fully supported.

6.6.            Status reporting

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

 

FULL COMPLIANCE

Tabular or graphical information of any classification of requirement (and associated (sub) system or other assigned category) is possible.

6.6.1.            Technical Performance Measurement status accounting

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

 

FULL COMPLIANCE

Charts {bar, pie, line} of fulfilled, partially-fulfilled and unfulfilled requirements can be generated showing relative performance of the project and user defined sub-projects for requirements creation, model creation, implementation and testing progress.

6.6.2.            Requirement progress/status reporting

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

 

FULL COMPLIANCE

Charts {bar, pie, line} of fulfilled, partially-fulfilled and unfulfilled requirements can be generated showing relative performance of the project and user defined sub-projects for requirements creation, model creation, implementation and testing progress.

6.6.3.   Other ad hoc query’s and searches

The requirements management tool should support ad hoc queries and searches per the user’s discretion.

 

FULL COMPLIANCE

CARE supports this in several ways. Firstly CARE has over 300 pre-defined searches that cover most typically encountered cases. Secondly, one may run an SQL search upon the requirement database. And finally, as a last resort, one may run a full text search upon any and all of the requirements documents. 

6.7 Support for generation and display of special character sets, mathematical symbols and formulas, and scientific notation, etc.

FULL COMPLIANCE

Very extensive support for logical and mathematical notation and foreign languages.

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

One of CARE’s greatest strengths, CARE supports world-wide distributed teamwork, seamlessly  whether on or offline, with version control and with a DoD-compliant security standard  for safe global communication.

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

Via a configuration tool, CARE supports many various levels of authorization for writing to the database. From read-only access, to non-binding change access to fully authorized, immediate changes depending on user permission authorization. Specific parts of the project may also have special authorization requirements. Version control also exists to handle possible discrepancies due to multiple check-outs the same requirements in the database.

 

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, PDM, etc.).  

 

 

8.1.1.            Interfaces to other tools?

What tools will your requirements management tool interface with or talk to?

 

FULL COMPLIANCE

Rational Rose and Together Control Center have product specific interfaces. For other interchanges, importing and exporting to Microsoft Word and Excel formats also exist. More generally, Rich Text Format based import/export functions exist to support inter-tool communication.

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

Our requirements database is accessible via an open API as well as COM and CORBA..

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?

 

FULL COMPLIANCE

CARE’s workflow-oriented database supports OO standard queries, SQL as well as RTF, Microsoft word and Excel formats..

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

CARE supports importing existing data in RTF, Microsoft word or excel formats.

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?

 

FULL COMPLIANCE

With version control, DoD-compliant encryption is the preferred way of exchanging information via internet-connection or direct dialup.

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

Datasets are version controlled to prevent dataset divergences. For special circumstances, automatic as well as manual functionality is available to compare and contrast datasets, for instance when first important data from another tool, word processor or spreadsheet.

9.          System Environment

9.1.      Single user/multiple concurrent users

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

 

FULL COMPLIANCE

Supports all user models. Single user and multiple concurrent users. One of CARE’s strengths is it’s secure multi-user, multi-location support.

9.2.            Multiple Platforms/Operating Systems?

Which platforms and operating systems does the tool run on?

 

Windows 9X, 2000, NT, Macintosh, OS/2, Linux and Unix.

9.3.            Commercial vs. proprietary database

Does the tool use a proprietary or commercially available database?

 

The database is commercially available and is used by several million users and has an open API.

9.4.            Resource requirements

Please identify hardware/software configuration requirements:

 

Screen resolution:

800 x 600

9.4.1  Memory requirements (MB)

client: 32 MB

server: 64 MB

9.4.2  CPU requirements

client and server: 200 MHz

9.4.3  Disk space requirements (MB)

client: 100 MB

server: 200 MB

 

 

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?

 

FULL COMPLIANCE

As many separate tasks as the user and/or computer can handle may be started and run simultaneously. Most agents (scripts/macros) are best run in the background.

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

Yes, when the model changes, all active views immediately reflect the change. MVC architecture.

10.3.            Interactive graphical input/control of data

Does the tool support graphical input and manipulation of data?

 

FULL COMPLIANCE

Graphical views allow drag-and-drop. Graphical objects may be embedded or url linked to requirements.

10.4.   Which window’s standard do you follow?

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

 

FULL COMPLIANCE.

Runs on Microsoft and Macintosh. The web-version is tuned for IE 5.0 or better.

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

Yes. Scripts/macros may be user-defined/recorded. CARE also comes with many built-in agents that can be manually or automatically executed for baselining, versioning, etc.

10.6.   Web browser interface

Does the tool allow a user to access the tool or database with a web browser?

 

FULL COMPLIANCE

Yes.

10.7  Undo Function

Does the tool incorporate an Undo feature?  Is it multi-level?

FULL COMPLIANCE

Yes, undo is multi-level.

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. 

 

ODBC, SQL, changeable templates that can be made to conform to any standard as well as our own pre-defined templates. CARE also supports Word, Excel and RTF formats.

12.          Support and maintenance

12.1.            Warrantee

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

 

FULL COMPLIANCE.

CARE comes with a standard software warranty such that when CARE is installed according to the instructions, it will comply with the supplied documentation and it’s requirements as well as a defect free media surface or we will replace it.  

 

12.2.            Network license policy

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

 

Multi-user, no license manager.

12.3.            Maintenance and upgrade policy

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

 

Yearly, more often if needed. Minor upgrades are free to customers with a maintenance contract. Major updates are 30% of the original license cost.

12.4.            Online help

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

 

FULL COMPLIANCE.

C.A.R.E. has on-line manuals, email support as well as its own help database that ships with the product.

12.5.            Internet access/World Wide Web home page location

Does the tool vendor have an Internet e-mail address and/or World Wide Web home page?  If so, what is the address and Uniform Resource Locator (URL)?

 

FULL COMPLIANCE

care@sophist.de

http://www.sophist.de/

12.6.            Phone support

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

 

FULL COMPLIANCE

Free Call: 0800 - SOPHIST (0800 - 7563377) or +49 09 11 - 40 900- 0

12.7  User's Groups

Does a User's Group exist?  If so, who is the primary contact?

 

FULL COMPLIANCE

Yes, we have a mailing list. care@sophist.de.

 

13. Training

 

13.1         Are tools specific training classes available?  What geographical areas?

 

FULL COMPLIANCE – SOPHIST offers extensive training seminars not just for Requirements Engineering but also for Requirements Management, OOA, OOD, and many other software engineering related topics and disciplines. These classes are available at the customer’s location.

13.2 Can training be made available at a customer's location?

FULL COMPLIANCE

Yes, classes are available at the customer’s location.

 

13.3 Amount of training required to become proficient with the tool (number of days)?

No training is required to use the tool. Knowledge about requirements management is strongly recommended to optimally use and understand the many features of CARE. Sufficient requirements management knowledge can generally be learned in 1 or 2 days. Courses for requirements engineering and management are available in several packages from SOPHIST Group.

 

13.4 Can software installation be performed by an individual with only basic training in the tool?

 

Yes, CARE can be installed without  tool training.

               

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

 

In our experience, we have found that it is very important to be able to link the requirements model with the OO software models. Furthermore, the requirements and OO models must be kept consistent with one another! To that end, we have created a general interface to any UML tool as well as product specific interfaces for Rational Rose and Together. We are the only RM tool that supplies this linking capacity.

 

Besides linking models with requirements, some notion of risk management is also very important in order for you to plan your project properly -- from lightweight to heavyweight requirements management. We integrate risk management into our recommended requirements management process eXtremeRM as well as our heavyweight Object Engineering® strategy – and our knowledge allows you to “tune” your project’s requirements strategy to anywhere in between. This insures that the necessary requirements management approach is applied and the right risks are taken and properly addressed with solutions that are commensurate to the problems.

 

This combined with our linguistic integration and requirement templates, high security standard and world-wide distributed team support, graphical and statistical overviews of project progress, workflow, and adaptability to a wide variety of project planning methods such as the V-model, OE or RUP, what more do we need to say?

Vendor Contact Information

 

Name: SOPHIST Technologies GmbH

Address: Vordere Cramergasse 11 – 13

                 90478 Nürnberg

 

 

Phone Freecall: +49 (0)800 – SOPHIST ( 767 – 4478 )

Phone: +49 (0) 911 - 40 900- 0

Fax: 09 11 - 40 900- 99

E-mail: care@sophist.de

Website URL: http://www.sophist.de/