QVscribe is a requirement authoring and analysis tool that harnesses Natural Language Processing (NLP) to proactively check for compliance of the best requirements analysis practices identified by associations such as INCOSE and against generally accepted industry frameworks such as Easy Approach to Requirements Syntax (EARS). It has been proven to reduce time and cost of reviewing requirements by 50% or more (QRA19).
Overview 1.1 1.2
The EARS methodology was first presented at the IEEE International Requirements Engineering (RE) Conference in 2009. It has since been widely adopted across the RE community to help users author clear, concise, natural language requirements easily, and improve RE workflows.
EARS classifies requirements into five EARS syntax patterns. These include ubiquitous, event-driven, optional feature, unwanted behaviour, and complex requirements. All of the syntax options have been formatted into automated templates within QVscribe (as seen in Figure 1) to create a fill-in-the-blank authoring process that is clear and compliant to EARS best practices. The templates are as follows: Ubiquitous Requirements: are not invoked by an event or input, nor are they limited to a subset of the system’s operating states.
The <system name> shall <system response>. State-Driven Requirements: are active throughout the time a defined state remains true.
While <in a specific state> the <system name> shall <system response>.
Event-Driven Requirements: require a response only when an event is detected at the system boundary. When <trigger> the <system name> shall <system response>.
Optional Feature Requirements: apply only when an optional feature is present as a part of the system. Where <feature is included> the <system name> shall <system response>.
Unwanted Behaviour Requirements: are often imposed when the system must respond to a trigger under less than optimum conditions.
If <trigger>, then the <system name> shall <system response>.
While <precondition(s)> when <trigger> the <system name> shall <system response>.
This feature allows users to standardize and automate their authoring process so that teams with multiple authors can write consistent requirements while also reducing misinterpretation. This consistency also creates an increase in efficiency in both the authoring and review processes. Within QVscribe’s Quality Analysis, the tool will check each requirement to see whether or not it is EARS conformant and which syntax is being used. This automated compliance check allows teams to ensure they are formatting requirements uniformly, avoiding ambiguities and misinterpretations. The INCOSE Guide for Writing Requirements (GFWR) is one of the most widely used and highly respected references in RE (INCOSE 2017). It provides a comprehensive set of 44 rules (as seen in Table 1) for helping users author clear and concise requirements. Previously, RE teams have had to manually train themselves and check for compliance to INCOSE which is a tedious, error-prone process. There are nine characteristics that every requirement should possess. They are necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct, and conforming. In addition, there are five characteristics that every set of requirements should possess. They are complete, consistent, feasible, comprehensible, and able to be validated. QVscribe uses NLP to assess if each characteristic is present in each requirement and identifies weaknesses to be corrected. Identifying these errors early on help to massively reduce risk later on in the project.
The latest version of QVscribe uses NLP to automatically measure compliance against these and is preconfigured to check for 24 out of 44 of the INCOSE Rules for Requirement Statements. The only rules that are not automatically checked by QVscribe are rules that require human action such as “R41: Use a project-wide style guide”. QVscribe will identify and alert authors to the use of passive voice, it is then up to the author to correct the error. Overall, it helps users automate the majority of requirements quality assurance tasks, reduces requirement review and correction time by as much as 50% or more, as seen by the RCAF and Ultra Electronics Marine Systems (QRA19), and allows RE professionals more time to focus on content rather than syntax. 1.4
QVscribe uses NLP to compare each requirement to all the others in the document and assesses requirement similarity on two levels; lexical and semantic. Lexical similarity compares requirements based on characters. Semantic similarity compares requirements based on their meaning. For example, “What is your age?” and “How old are you?” are typed quite differently but essentially have the same meaning therefore their lexical similarity would be low, but their semantic similarity would be high. This feature enables requirements engineers to ensure there are no redundant or duplicate requirements. This is especially valuable to teams with multiple authors collaborating on one document where different authors could have expressed the same requirement in different ways. Avoiding redundancies is crucial to improving efficiency and reducing rework which inevitably increases over time as they lead to additional time spent correcting errors along in the development process. 2 Plan for Demo This demo will be an overview of how QVscribe functions and improves RE workflows. The demo will use an existing requirement document example to show a variety of issues and demonstrate how QVscribe addresses them.
The presenter will demonstrate that when the user clicks on a requirement, QVscribe highlights any issues and gives suggestions based on industry best practices so that authors can easily improve their requirements prior to review. With QVscribe, users can now edit and receive feedback in real time, aiding significantly in the training and knowledge transfer process. Next, the presenter will explain QVscribe’s automated EARS templating feature which allows engineers to use fill-inthe-blank templates to standardize their authoring process and reduce time and misinterpretation. They will show an example of a couple of the templates, when to use them and how to fill them in, as well as showing that the Quality Analysis will identify when requirements are EARS conforming. Then they will show examples of poorly authored requirements and how to correct them. Firstly, the presenter will show a requirement with a quality issue, for example, no imperatives, they will show how QVscribe highlights that error, then they will fix the error and reanalyze the requirement to show a new requirement with a high quality score.
Next, the presenter will show an example of a unit consistency issue and explain the value of this analysis and how to utilize it in one’s workflow. For example, requirements listing some speeds in km/h and some in mph, including an explanation on how QVscribe identifies these issues and how to fix them if/when necessary.
The presenter will go into Similarity Analysis and provide an explanation of lexical and semantic similarity, including the difference and importance of both. This includes an example of requirements that are not lexically similar but have a significant semantic similarity.
Finally, the presenter will generate a PDF report which includes all of QVscribe’s analysis, including a breakdown of all the Quality Indicators, each requirement highlighted to show any issues, Unit Consistency, Term Consistency, and a list of all the terms in the document. The presenter will also explain the value of having these easily shareable reports for collaboration across teams. [QRA19] QRA. How Ultra Electronics Maritime Systems Reduced the Time and Cost to Revise Requirements by 75% or
More, February 2019. [INCOSE17] INCOSE. Guide for Writing Requirements, June 2017.