rCoach One User Guide

Working with rCoach One

Working with rCoach One is designed to be both flexible and adaptable.

Open a Specification

There are three ways to open a Specification in order to analyze it:

  • Through the Spec button in the main window Toolbar;
  • Through File > Recent Analysis in the application menu;
  • By dragging and dropping a Specification file in the Specification path field in the main window.
Trulli

Specification validation

The Specification is validated when opened. A valid Specification needs to have a well-formed XML document that satisfies the DTD specification. A valid Specification displays the file path in the main window. A Specification that is not valid will display an error panel. Only valid documents can be analyzed.

Apply rules for analysis

Analysis rules can be applied on two levels: the Specification level and the requirement level. Rules on Specification level apply to most of the Specification contents, except to the requirements themselves. Requirement rules apply only to the requirements, with some exceptions. The user can apply requirement rules to a few other elements, thus enforcing a more strict analysis of the Specification.

A violation of a requirement rule is considered more severe than the violation of a Specification rule. The User cannot change the severity of a rule.

Rule settings are saved in user defaults. Rule settings can be saved in a Configuration file for other Users to import. The configuration can also be stored in the Data Repository. Configuration files make it easier for Project Management, Quality Assurance and Specification Authors to distribute configuration settings to other members in the Project.

Analyze a Specification

A valid Specification is analyzed when clicking the Analyze button in the main window Toolbar. When a rule is violated, a serious or minor Issue is generated. All Issues can be browsed in the Navigate > Issues view.

View Issues

Select Navigate > Issues to show all issues generated during analysis. Issues can be browsed on three different levels, each level is selected by opening the Issues Panel.

  • The Specification level
  • The requirement level
  • The element level

The Specification level displays the formatted Specification chapter by chapter, including sub-chapters. Selecting an Issue in the Issue table highlights the formatted text where the Issue was generated.

The requirement level displays individual requirements. Nothing besides the requirements are displayed.

The element level displays individual XML elements.

The formatted contents is browsed through the arrow buttons, or by using the expanded outline view. Which Issues are displayed can be filtered through the Issue filtering panel.

View metrics

Detailed metrics can be viewed in Navigate > General Metrics, Navigate > Specific Metrics or Navigate > Graph. Metrics are divided into two main groups: General Metrics and Specific Metrics. To facilitate data mining, the General Metrics group is aggregated on five levels: the Specification level, the plain text level, the rationale level, the requirements level, and the example level. The Metrics on the Specification level is the sum of the metrics on the other four levels, with some additions.

Edit a Specification

After performing analysis of a Specification, the Author corrects generated Issues by opening the XML Editor. The XML Editor displays three separate views: an Outline view for navigation, a text view for the formatted content, and a text view for the XML content that can be edited. The formatted content cannot be edited.

Editing a Specification is like programming. XML elements are edited and analyzed individually in the Editor. To speed up the writing-analyzing-correction cycle, several services are available from within the Editor. The Specification can be formatted and validated, old revisions can be displayed, the editing is supported through code completion. When the Author is satisfied, the whole Specification can be analyzed again in the main window. The writing-analyzing-correction cycle is designed to be supportive and allow different ways of working.

Test a separate statement

To test individual statements, either they are requirements or plain text, without having to deal with a complete Specification, a Test statement window can be opened. The window is opened from Navigate > Issues, or from Edit > Test Statement… in the application menu. Single statements are written in the window, rules are activated, and the statements are tested. Quality and information content is measured for requirements, and information content is measured for plain text.

The Test statement window can be used for testing Statement of Compliance (SoC) , RFPs, or RFQs. The window can be used for testing Project Goals, Quality Goals, or other types of important contents.

Generate reports

Reports can be generated after a Specification has been analyzed. A Report contains Specification information, General and Specific metrics, the analysis configuration, and the bottom ten requirements found.

Reports can be generated for both Specifications that have been analyzed, and for Specifications that are in the Data Repository.

Export requirements to a spreadsheet

Requirements and their attributes can be exported to a CSV formatted file (Comma Separated Values). The CSV file can be imported into Apple Numbers, Microsoft Excel, or other spreadsheet programs that can handle the CSV format.

The export function enables a Project Manager or those responsible for Quality Assurance to integrate analysis results with other parts of the project, in order to follow up progress and quality.

Work with Configurations

Analysis configurations can be saved as a file or be stored into the Data Repository. Configuration files contain the status of rules (active, not active), min and max limits for Specific metrics, and defined Attributes and their values.

The Configuration file can be distributed to other project members by e-mail, or stored in the Data Repository for traceability.

Qualify a Specification

A project needs to follow up on the status of a Specification, both before and after the Specification is released. Each requirement is assigned a set of attributes which describe the various needs a project may have. Attributes could reflect the current implementation state for each requirement, the risk level of each requirement, the cost to implement, etc. A Specification must be stored in the Data Repository in order for the requirements to be assigned Attributes.