INTRODUCTION

Writing clear, unambiguous requirements in natural (spoken) language has never been easy. In the context of requirements definition, the inherent imprecisions and ambiguities of natural language can frustrate even the best of writers. Since at least the 1970s – long before the term ‘requirements engineering’ came into general use – engineers have sought ways to overcome the weaknesses of natural language as a medium for requirement specification. “Natural language’s extensive vocabulary and commonly understood syntax facilitate communication and make it an inviting choice to express requirements,” says William Wilson, a former principal systems engineering consultant with the Software Assurance Technology Center (SATC). “The informality of the language also makes it relatively easy to specify high-level general requirements when precise details are not yet known.

“However, because of differences among formal, colloquial, and popular definitions of words and phrases and the effort required to produce detailed information, these same attributes also contribute to documentation problems. The use of natural language to prescribe complex, dynamic systems has at least three common and severe problems: ambiguity, inaccuracy, and inconsistency.”

Until recently, most of the proposed solutions to these problems have fallen into two classes: (1) modelling languages, which eliminate the use of natural language in specifications, and (2) best practice guides, rule sets or checklists for writing better natural language requirements.

Unfortunately, each of these two solution classes comes with problems of its own. One raises barriers against less technical stakeholders. The other burdens engineers with a time-consuming task, much of which is menial.

THE DRAWBACKS OF MODELLING LANGUAGES

Numerous requirements modelling languages are now in use. They range from semiformal languages like Unified Modelling Language (UML), User Requirements Notation (URN) and other graphical notations, up to formal methods like Z-notation, KAOS and proprietary model-based systems engineering (MBSE) tools. The main problem with modelling languages is that they cannot be used throughout the entire systems engineering processes.

All the languages mentioned above, and others like them, were designed for communication between engineers. They weren’t intended for communication with project stakeholders who aren’t directly involved in system development – like executives, managers and business analysts.

Furthermore, they are all designed primarily for software development. Even model-based systems engineering focuses on domain models, a concept from software engineering. Domain models are designed to capture functional requirements and define information flow. They can’t be used for specifying non-functional requirements. And while domain models can be used to convey concepts to non-technical stakeholders in presentations – since they use the vocabulary of their user domain – non-technical stakeholders may not be able to interpret the models on their own, without training.

In most cases, modelling languages are inappropriate for many stakeholders. Project stakeholders may come from a wide variety of backgrounds and disciplines. They represent a broad spectrum of interests. They may write or review requirements only occasionally, and only then in higher-level specifications. Those who have non-technical roles – even those with technical backgrounds, like engineering managers – will likely be unfamiliar and uncomfortable with the latest modelling languages. Their responsibilities rarely afford them enough time to become fully conversant in such languages.

As a result, according to a recent study, some 95% of engineering specifications use some form of natural language (79% use common natural language, 16% use structured natural language) to express requirements. ⅱ

THE DRAWBACKS OF BEST PRACTICE GUIDES, RULE SETS AND CHECKLISTS

To assure requirement quality in natural language specifications, the most common tool is some sort of best practice guide or checklist. These may be developed internally or by some expert third party. Constructing such guides and checklists is a tricky proposition, however. It’s difficult to strike a balance between comprehensiveness and usability.

One of the most common weaknesses of house-built requirements rule sets and checklists is that they are not comprehensive enough. Built to be easy to use during requirements authoring and review, they don’t cover all the bases of natural language requirement specification. They leave gaps in the skill sets of those using them, and in the best-practice vocabularies of their organizations.

In contrast, third-party requirements quality guides tend to be so comprehensive that they prove difficult to use during authoring and review. They’re great for developing skill sets, but – like modelling languages – they demand much time and practice to be fully absorbed.

Perhaps the most well-known, respected, and widely used of these third-party guides is the Guide for Writing Requirements published by the International Council on Systems Engineering (INCOSE).

Originally published in December 2009 and revised a dozen times since, the INCOSE Guide for Writing Requirements (GFWR) is comprehensive, well-structured and highly readable. It is probably the most complete set of best practices for authoring natural language requirements. The GFWR is an excellent reference for organizations seeking to embed RE best practices and train new team members, as well as for individuals looking to improve or brush up their RE skills.

Unfortunately, the same attributes that make the GFWR a great reference also make it rather unwieldy in the requirements review process. The GFWR’s forty-one rules require more than thirty pages of explanation. Just listing them takes up two pages in the GFWR’s summary sheet. Manually reviewing every requirement in a major set of requirements (a specification or a large change to a specification) against forty-one different rules is an arduous, tedious and time-consuming process.

A BETTER WAY TO ENFORCE RE BEST PRACTICES

In response to the problems mentioned, an emerging class of analysis tools is greatly reducing the tedium of requirements review. These tools are helping engineers achieve a high level of clarity in natural language specifications without imposing an added learning curve on stakeholders.

Using advanced natural language processing (NLP) technology, these tools complete in seconds tasks that humans take hours to perform. They automatically analyse individual requirements against known RE best practices and point out requirements that need attention. This automated analysis streamlines the requirement review process and frees domain experts from tedious tasks that don’t require their domain knowledge. The domain experts’ expertise and intervention are still required, but these tools help them to be more focused and efficient.

In much the same way that syntax checkers and debuggers help software refine code, these analysis tools help engineers and analysts refine requirements. They provide a quality assessment of each requirement analyzed, cueing users to possible sources of ambiguity and allowing them to quickly correct problems before sending their requirements for formal review. They’ve been shown to reduce requirement review and correction time by 50 to 75 percent. ⅲ , ⅳ

Leading this technology advance is QRA Corp’s QVscribe, an add-in for Microsoft Word and Excel. QVscribe analyses the quality and consistency of requirements inside those applications. By integrating directly with the most popular requirement authoring tools, QVscribe helps engineers and analysts reduce ambiguity and improve clarity in requirements at the earliest stages of development. By highlighting potential requirements errors and ambiguities during the requirements definition phase of a project, QVscribe helps engineers reduce those errors and avoid implementation errors early, when they are least expensive to fix. Studies have shown the cost of fixing engineering errors in systems and software increases exponentially over the project life cycle.

QVscribe offers requirements engineers and analysts at least three major benefits.

First, QVscribe saves time in requirements analysis. Even the largest specifications with thousands of requirements can be evaluated in seconds. Systems RE professionals get quick feedback on all the requirements they’ve authored or need to analyse.

Second, QVscribe generates reports which show users where work is needed. They provide visual scoring of each requirement assessed. Engineers and analysts can see immediately which sections of the document and which specific requirements need the most work. Project managers and decision makers receive written verification that all ambiguity issues have been adequately addressed.

Finally, and most importantly, QVscribe automates a tedious task. Manual review of requirements documents – even portions of those documents or changes to them – is a fatiguing and time-consuming task when one is armed only with a long checklist of RE best practices. It’s not the best use of a domain expert’s valuable time and know-how. QVscribe aids domain experts by making their search for potential problems much faster and more accurate and by showing them where they need to apply correction.

By automating the checking of requirements against a host of RE best practices and indicating where intervention is needed, QVscribe not only saves RE professionals time and effort – and keeps their minds fresh for more interesting work. It also helps those who are relatively new to requirements engineering gain greater proficiency in its best practices – more quickly and at a lower training cost. It’s almost like having an expert looking over the trainee’s shoulder. As one recent engineering graduate put it, “I was happy to have a tool that would not only identify deficiencies in my requirements, but also help me learn the big do’s and don’ts of requirement writing. We have references on good requirement writing, but QVscribe is faster.”

ANOTHER BEST PRACTICE THAT CAN HELP

Naturally, QVscribe can be used in conjunction with other RE tools, methods and best practices to ensure your natural language requirements are as clear and unambiguous as possible. One method we especially like is the Easy Approach to Requirements Syntax (EARS).

EARS is an approach based on five patterns for writing five fundamental types of requirements. The patterns can also be combined to write more complex requirements. EARS makes writing clear, concise, unequivocal natural language requirements much easier, while also making those requirements much easier to read.

To find out more about EARS, check out our Definitive Guide to the Easy Approach to Requirements Syntax.

CONCLUSIONS

Many of the same properties that make natural language an attractive medium for expressing engineering requirements are also weaknesses of that medium; they make it easy to introduce ambiguities which can lead to design errors.

For decades, the most popular methods used to try to overcome those weaknesses were modelling languages and best practice rule sets or checklists. Unfortunately, both of those methods have drawbacks of their own.

The rising trend in natural language requirements engineering is toward greater use of purpose-built NLP analysis tools like QVscribe. QVscribe streamlines RE workflows by providing rapid requirement analysis, showing domain experts where intervention is needed, and automating the requirements review process. QVscribe thus gives systems engineers, engineering managers and business analysts more time to focus on tasks that truly require their expertise.

FOR MORE INFORMATION

For additional information on how QVscribe can be used automate RE best practices download our free automation guide: Automating the INCOSE Guide for Writing Requirements.

To learn more about QVscribe and find more helpful resources for improving your requirements and your RE processes, visit qracorp.com/qvscribe.

To discover how QVscribe can help your organization improve and accelerate its requirements definition and analysis processes, click here to schedule an online demonstration.