INCOSE Requirements Management Tools Survey
SpeeDEV 3.5
Software Lifecycle
Management
SpeeDEV is a Web-based tool for managing engineering projects from Requirements Management to Product Release. SpeeDEV provides:
SpeeDEV is a faster, more cost-effective way to ensure that best practice methodologies can be automated and enforced across the project team, resulting in exceptional software delivery and management.
Last Updated: October 2002
Outline
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.
NONE.
1.1.1. Input document change/comparison analysis
The ability to compare/contrast two different versions of a source document
FULL. Requirements can be compared/contrasted by version number or source.
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. Requirements can be automatically identified by their meta-data.
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?".
NONE.
1.4. Manual requirement identification
A manual means of identifying or creating requirements.
FULL. Requirements can be entered directly into the application via a web browser or through a web services interface.
1.5. Batch mode operation
A mechanism for inputing/identifying requirements from outside of the tool.
FULL. Requirements can be imported from Excel spreadsheets or delimited text files.
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. Updates can be performed at any time.
1.6. Requirement classification
Does the tool have the ability to classify/categorize requirements during identification?
FULL. All Requirements details can be customized during entry or importation.
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. Any graphical artifact can be attached to requirements and previewed in the web browser (note: plug-ins may need to be installed for non-standard content types).
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. Requirement text
can be entered, displayed, and linked.
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. Requirements can be linked to each other, organized in a hierarchy, or attached to each other.
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. In addition to system elements such as risk, priority, and criticality, custom elements such as weight, cost, or your own proprietary metrics can be allocated to performance requirements.
3.3. Bi-directional requirement linking to system elements
The linking of requirements to system elements can be accomplished from either end of the link--from the system element (implementation or test) back to the requirement or from the requirement down to the system element.
FULL. Bi-directional requirement linking is supported.
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. Requirements can be linked to Issues. In addition, each Requirement or Issue can use custom fields to capture details such as rationale, accountability, etc.. These fields can be displayed based on Requirement Type or User Access Privileges. The values for the fields can also be automatically assigned based upon Business Rules.
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. Traceability will raise impact flags for inconsistencies or changes to requirements.
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. Traceability relationships can be viewed and followed.
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. Requirements can be Open, In Progress, Deferred, or Closed. Each Requirement is assigned to an individual responsible for that requirement.
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. Custom queries can be created to report variance of allocated values versus actual values.
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. Change and Processing history for each requirement is maintained, including the date, source, and description of the event.
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. Baselining Requirements and Issues is included.
5.3. Access control (modification, viewing, etc.)
The requirements should be able to be protected from modification, viewing, etc. by individuals or groups.
FULL. Access permissions to Requirements are managed by individual or group.
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. Reports are customizable to any format.
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.
PARTIAL. Reports can be exported to MS Word for document consistency checking.
6.3. Presentation output
Once the information is loaded, the requirements management tool should support the generation of presentation quality charts and graphs.
FULL. Queries, Views, and Reports with tables and graphs are included.
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. Reports are generated with Crystal Reports and can also be exported to MS Word.
6.5. WYSIWYG previewing of finished output
The tool should allow the user to view the document on-screen in finished format.
FULL. Formatted Reports can be viewed in a web browser.
6.6. Status reporting
Tool users need to status information in the requirements management tool.
FULL. Status information can be generated in the tool or synchronized with MS Project.
6.6.1. Technical Performance Measurement status accounting
Status current technical performance of various allocated performance requirements and monitor progress towards goals.
FULL. Requirements can be managed by percent completion or by progress in workflow.
6.6.2. Requirement progress/status reporting
Status reporting on current compliance/non-compliance to various requirements
FULL. Automated rules can be created to send notifications or update status based upon compliance or non-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. Our user-friendly query interface allows customized searches. Text searching is also supported.
6.7 Support for generation and display of special character sets, mathematical symbols and formulas, and scientific notation,etc.
NONE.
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.
FULL. The web browser interface allows distributed teams to collaborate on requirements.
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. Multiple users can review, edit, and comment on requirements. In addition, built-in workflow allows the coordination of any activity or task associated with requirements.
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. Records are locked when currently being edited to prevent data entry collisions. User permissions are also defined to limit access to different types of information.
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?
FULL. Crystal Reports and MS SQL Server for report generation, MS Project for Gantt charting, iManage for linking to content management, Visual SourceSafe, PVCS, and CVS for versioning attachments, and Mercury TestDirector for testing integration, SOAP for external web services, amongst other tools and interfaces. Integration with your toolset is available upon request.
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. MS SQL Server is used for data storage and can be accessed directly. Web Services is also supported for API access to SpeeDEV.
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.
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. User can import delimited ASCII text files with default structures and values.
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. Entire projects or individual requirements can be exported/imported between different installations (note: administrator accounts only).
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. Supported through MS SQL Server.
9.1. Single user/multiple concurrent users
Is the tool support a single user or multiple concurrent users?
Multiple concurrent users.
9.2. Multiple Platforms/Operating Systems?
Which platforms and operating systems does the tool run on?
Server component requires MS Windows 2000 Server with IIS. Client runs on MS Internet Explorer 5.0 and above (no additional software installation required).
9.3. Commercial vs. proprietary database
Does the tool use a proprietary or commercially available database?
SQL Server 2000 is commercially available from Microsoft.
9.4. Resource requirements
Please identify hardware/software configuration requirements:
9.4.1 Memory requirements (MB)
512 MB (2 GB recommended).
9.4.2 CPU requirements
800 MHz or greater.
9.4.3 Disk space requirements (MB)
100 MB for application, 2 GB recommended for data.
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.
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?
PARTIAL. Changes are reflected upon page refresh.
10.3. Interactive graphical input/control of data
Does the tool support graphical input and manipulation of data?
FULL. Several aspects of the application support interactive control, including traceability and process design.
10.4. Which window’s standard do you follow?
If your tool supports a window’s standard, which one(s)?
FULL. SpeeDEV supports the W3C standards of DHTML, DOM and XML.
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. Rules Manager supports the creation of business rules.
10.6. Web browser interface
Does the tool allow a user to access the tool or database with a web browser?
FULL. The application is completely web based.
10.7 Undo Function
Does the tool incorporate an Undo feature? Is
it multi-level?
NONE.
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.
SpeeDEV supports industry standard software development methodologies, such as RUP, Xtreme, CMM, and Waterfall. The application supports SOAP, SSL, COM/DCOM, and web-based .NET architecture.
12.1. Warrantee
Does your tool have a warrantee, if so what is it?
Warrantee to work as stated.
12.2. Network license policy
Does the tool support network licensing (floating, node locked, etc.), if so which license manager?
Named user or concurrent licensing supported.
12.3. Maintenance and upgrade policy
How often are software updates released; are updates separately priced items, etc.?
Updates are released quarterly and are included as part of the maintenance agreement.
12.4. Online help
Are the users manuals online, is there online help with the tool?
Installation and User Guides are provided. An online tutorial and context sensitive help is included 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 address and Uniform Resource Locator (URL)?
http://www.speedev.com/ ; sales@SpeeDEV.com
12.6. Phone support
What type of phone support is available from the tool supplier?
Standard Telephone Support hours: 9.00 AM to 5.00 PM PST - 2 hour call back time during business hours.
24x7 Telephone Support hours: During 9.00 AM to 5.00 PM Pacific standard time - 1 hour call back time within business hours, Off Hours - pager based support - 2 hour call back time.
12.7 User's Groups
Does a User's Group exist? If so, who is the primary contact?
Please contact Support@SpeeDEV.com for User Group information.
13.1 Are tools specific training classes available? What geographical areas?
Administrator and User training are available in San Jose, California.
13.2 Can training be made available at a customer's location?
Yes.
13.3 Amount of training required to become proficient with the tool (number of days)?
One day.
13.4 Can software installation be performed by an individual with only basic training in the tool?
Yes.
14. What other requirements management features do you as a tool supplier think are important (modeling, etc.)?
Please visit our website at http://www.speedev.com/ for more details.
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