More on rCoach One – Slingblade

rCoach One

Operating requirements

rCoach One release 1.4 requires:

Apple silicon or Intel-based Mac;
4GB of RAM (8GB recommended);
macOS 11.0 or later;
35 MB of available disk space.

Simple workflows

rCoach One is developed for natural language requirements writing and analysis. It is designed for simple workflows and flexibility. You can use all functionality provided by the tool, or only the parts you need.

Specifications are written on an XML format, using the English language;
The XML tag decides what active rules will be applied during analysis;
From your quality goals, decide what analysis rules to activate;
Define attribute names and attribute values that is assigned to requirements after the Specification is stored in the database.
Save the analysis configuration to a file or store it in the database;
Analyse the whole Requirements specification with one click. Browse all issues in the Issues view;
Analyse general and specific metrics to decide what Specification parts need to be improved;
Generate a Report that contains Specification information, metrics and rules used during the analysis;
Whenever the moment is right, store the specification into the database;
Use Statistical Process Control (SPC) to analyse process integrity;
Use the Test statement window to easily test individual requirements or paragraphs without having to write a whole Specification;
Use the Help book to solve any issues or questions you have;
Make a backup file of your database, or restore the database from a backup file;
The database is hosted on the same computer where you installed the application. The database is a single user database that requires virtually no maintenance.

A sophisticated analysis engine

Rule based analysis ensures that a Requirements Specification fulfills certain standards set by a project.

If the analysis engine detects a violation of an activated rule, a Serious or minor issue is generated, depending on the type of rule.
Serious Issues can ultimately introduce deficiencies in the final product;
Minor Issues can lead to less clarity of a subject;
The analysis engine contains sophisticated Natural Language Processing (NLP) to detect rule violations;
Active rules can be escaped by making definitions of Actors, terms, and abbreviations;
Rule based analysis gives a qualitative insight into the content of a Requirements specification;
Statistical process control (SPC) and control charts give a quantitative insight into the behavior of the requirements writing process;
By identifying and occasionally removing sources of variability, process stability can be ensured and performance improved, thereby increasing the possibility for a project to reach high level goals that are expressed in terms of schedule, quality or cost.

Rules on Specification level

Specification content is, with some exceptions, defined as everything except the actual requirements. It is meta information found in the beginning of the document, plain text paragraphs and headings, rationales, examples, appendixes and references. The user has some possibilities to define what is regarded as Specification content and what is regarded as requirements content during the analysis phase. There are 36 rules on Specification level you can activate after your own choosing. Rules concern such topics as:

Chapter depth, chapter length, paragraph length, and sentence length;
Rules on required elements, such as a subtitle, a revision history, and classification;
If a glossary is required, and if appendixes and URLs are allowed;
If rationales and examples should be treated as requirements;
Spell checking of U.S. English, Australian English, British English, Canadian English and Indian English;
Calculation of four different readability indexes;
Automatic numbering of paragraphs, chapters, figures, and tables;
Checking numbering sequences of chapters, tables, and figures;
Prevent analysis of headings and references;
Checking of grammar in non-requirements, such as the usage of nominalizations, passive voice, adjectives, and adverbs;
Application of requirement rules on pronouns, and expressions of inexact quantity.

Rules on requirement level

Rules on requirement level apply to requirement text elements. Some of the rules can also be applied to the Specification level. There are 172 rules you can activate after your own choosing. Rules on requirement level concern such topics as:

Calculation of four different readability indexes;
Allowed modal forms: shall-form, present tense, will-form, should-form, and must-form;
Checking the requirement structure: unique tags, the presence of a requirement version, the presence of a rationale in chapters that contains requirements. If figures, tables, lists, and URLs are allowed in requirements;
Maximum sentence length;
Checking for subordinate clauses;
Checking of grammar: nominalizations, passive voice, adjectives, and adverbs;
Usage of conjunctions, such as "and", "or", "but", "either...or";
Usage of pronouns, such as "I", "he", "it", "this", "which", "any", and "nothing". There are in total 69 rules on pronouns that can be activated.
Rules on expressions of inexact quantities, such as "all", "each", and "several". There are 40 rules that can be activated.
Rules on special lexicals, such as the usage of parenthesis, questions mark, and quotes;
The usage of special expressions, such as "T.B.C.", "etc.", "and so on", and "e.g.".

Metrics

Metrics are tied to activated rules on Specification and requirement level.

There are 30 general metrics and 23 specific metrics;
General metrics are aggregated on four different levels: the Specification level, the plain text level, the rationale level, the requirement text level, and the example level;
General metrics are unweighted, while specific metrics are mostly weighted;
Examples of general metrics include the number of serious and minor issues; the number of requirements, adjectives, subordinate clauses, and misspelled words;
Four different readability indexes are measured for general metrics;
Examples of specific metrics include serious issue density, minor issue density, form inconsistency, actor frequency, adjective frequency, and subordinate clause frequency;
Specific metrics can be assigned a lower and upper limit to indicate acceptable values. Out of bound measurements are colored in red.

Graphs

More than 65 different graphs can be plotted. They include:

A time scale chart when different Specification versions were stored into the database;
Trend-line graphs and XmR-charts for general metrics;
XmR-charts and u-charts for specific metrics;
Scatter graphs and box charts for requirements quality and information measurements;
Pie charts and bar charts for requirement attributes, and attribute trends;
Use one of eight predefined color schemas to make your graphs pop, or use one of your own.

The Editor

The XML Editor contains functions that will help you write and analyse your Specification.

Eight different templates to start with, from a Standard specification, to an App specification, a Business specification or a Functional Safety specification for automotive;
An outline view describing chapter headings and individual requirements that can be easily navigated;
A formatted Specification view;
The XML text view, where all editing is made;
Automatic indentation and formatting of the XML text;
Analysis of individual XML elements by inserting the caret in the text and using the "cmd-Return" keys;
View all stored versions of a single requirement inside the XML text view;
Analyse changes between any two versions of a Specification. One of the versions must be stored in the database;
Create and edit Review comments directly inside the editor;
Export the Specification to either Word, PDF, RTF or plain text format;
Smart insertion of XML elements by placing the caret where the new element should be and using the "Enter" key.
A context sensitive menu that suggests XML elements that can be inserted;
Check for database storage issues before the Specification is stored into the database.