Note: This is a follow-on to our previous blog: Requirement Quality: Garbage In; Garbage Out

Many of today’s requirement management tools (RMTs) focus on (1) documenting requirements and other associated information and (2) the relationships (trace) between requirements and the other information (attributes) associated with the requirements.  However, as stated or the previous blog, few RMTs currently address the quality of the requirements managed within the tool thus allowing the user to input and manage poorly written requirements –  hence the saying “Garbage in; garbage out.”

Fortunately, The REUSE Company (TRC), has developed the Requirement Quality Suite (RQS) of tools, using natural language processing, that focus on the quality of individual requirements as well as sets of requirements.  TRC has designed the RQS of tools to integrate with existing RMTs, so the TRC tool set can interact with the requirements being managed within an RMT using “Connectors”.

Currently, TRC has developed “Connectors” for the following RMTs: IBM DOORs, PTC Integrity, Visure Requirements, CATIA Reqtify, OSLC, XML file, and MS Office (Excel).  Given 6-8 weeks, they can develop a connector for any RMT.  Also, they are currently working on developing connectors to work directly with MS Word and Siemens Teamcenter.

The software suite:

The RQS is a set of tools aimed to plan, customize, measure, control, manage and improve the quality of your system work- products, especially of your requirements specifications.   RQS is aimed to assess most of the requirement quality characteristics described in well-known industry and international standards including the INCOSE Guide to Writing Requirements. Those characteristics are assessed by means of objective and easy to measure metrics (a.k.a. rules or indicators) that can easily be customized according to the level of maturity of the organization, domain, and project and matching the set of guidelines or checklists defined in the organization.   The three main applications in TRC’s RQS include Requirements Quality Analyzer (RQA), Requirements Authoring Tool (RAT), and Knowledge Manager (KM).

RQA allows requirement Quality Assurance (QA) team to customize the metrics according to the active requirement development guidelines and checklists of the organization. RQA also helps with requirement verification activities when they are part of the requirement baselining process, verifying the requirements are written consistent with the organization’s requirement quality standards.

RQA does batch processing of a set of requirements allowing one to look at individual requirement quality and defects within the set and then rewrite the defective requirements to correct the defects.  Having this capability results in higher quality requirements. These batch jobs can be automatically scheduled to occur at periodic intervals.  The result is a quality assessment (correctness, consistency, completeness) of the requirements.  RQA generates reports with metrics that allow one to see what types of defects are present, whether or not the number of defects are decreasing, and thus whether or not the overall quality of the requirement set is improving.  The user can develop graphs showing specific information on quality and even keep track of quality on an author-by-author basis.  Having this knowledge will help improve training and improve the overall requirement writing process.  RQA can be customized with an organization’s own quality policies and requirement quality checklists.

RAT is intended to be used by authors to assist them while they are creating or editing requirements.  RAT identifies correctness and consistency defects as the requirements are written so that higher quality requirements are input into the requirement set from the beginning.   When using RAT, the author first selects a template from a pull down menu and then RAT will aid in authoring a well formed requirement based on the knowledge base and selected template.

KM is the core of the RQS.  KM allows the user to define and manage a knowledge base (referred to as the ontology) tailored for each customer organization with the semantics, vocabulary and basic concepts and relationships of this knowledge.  This knowledge includes an acronym list, glossary, Product Breakdown Structure (PBS), key nouns, verbs, etc. associated with the user’s domain. Using KM, a set of templates are defined for various types of requirements the organization uses. A template represents the grammar, structure or pattern the text that makes up a requirement has to follow according to the policies of the organization.  Templates are used to state which set of grammars and vocabulary should be followed by the various types of requirements in the customer’s projects.  TRC has many of the common templates predefined.

For example, the following requirement fulfills the following template:

“The Radar shall detect airborne objects at a minimum rate of 10 units per second.”

The <system> shall <Action> <Object> <Performance information>.

Then the last block should be, in turn, decomposed within the following level of detail: <Performance information> := at + minimum + rate + NUMBER + <Unit>

For complex projects, it is extremely important to have defined a common ontology to maintain consistency between requirements in a set as well as consistency between sets of requirements for each part that makes up the PBS.  KM gives the ability to do this.

RQA and RAT use the knowledge base created and managed by KM to access the quality of the requirements.

Implementing TRC’s suite of tools:

To implement TRC’s suite of tools, someone in the organization will have to be assigned the role of the Knowledge Repository Manager (KRM).  This person has to have the domain knowledge of the vocabulary, semantics, and templates for the organization using the RQS.  This person or an assistant will also have the role of the Knowledge Base Architect (KBA) to lead the efforts needed to manage the activities associated with defining, inputting, and managing the knowledge base. The main responsibilities of this role are the following:

• Agreeing, together with other roles, the borders of the domains to be modeled within KM
• Finding sources that could help in the creation of the knowledge base
• Creating and evolving one or more knowledge models within the business domain
• Defining the right structure (boilerplates) of the requirements to be written
• Attending the suggestion of system engineers and business analysts to evolve the models

The RQS functionality is directly proportional to the maturity of the knowledge base.  The knowledge base as it comes out-of-the-box include a generic set of metrics, allowing an organization to use the tool set starting on the first day.  However, to get the most out of the tools, the organization will want to tailor the knowledge base to their specific domain, processes, and products.  

Note: While this may seem to be a lot of upfront work, keep in mind that within a given domain within an organization, there will be a high degree of reuse of the knowledge base for other current and future projects.

Special training workshops will need to be developed so that everyone in the organization that will be using these tools understands 1) the ontology, 2) the templates, 3) how to write good requirements based on the ontology, and 4) how to use the tools.

If your organization is not currently using one of the RMTs that TRC has already developed a “connector” for, then arrangements can be made for TRC do develop the needed “connector”.

Comments are welcome.