Easy Approach to Requirements Syntax (EARS)... with ChatGPT
Introduction
As an engineer and technologist?I've been?exploring ChatGPT?capabilities and sharing outputs in a series of articles
Interest peaked with a provocation on Requirements Engineering. Respected practitioners pressed on form. I also was minded to explore use of defined rulesets... So we're back with an article to demonstrate draft and verification of requirements
ChatGPT?and I wrestled on this one. Products are respectable but more time, trials, and training data is evidently needed to perfect form, particularly for optional feature and complex requirement types. However, we may reasonably expect improvements in short course. I guess this is akin to skills training and development
See following expert groups, guidance, and practitioners for allied instruction: INCOSE Requirements Working Group, IREB, and Alistair Mavin (originator of EARS).
Check out the results below and follow-up with feedback in the comments.
Primary System Functions
EARS Requirements
Verification of Requirements
My scripted prompts
I am going to advise you of pattern rules and syntax for Requirements. This ruleset is known as the Easy Approach to Requirements Syntax (or EARS).
Generic EARS syntax
The clauses of a requirement written in EARS always appear in the same order. The basic structure of an EARS requirement is:
While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>
The EARS ruleset states that a requirement must have: Zero or many preconditions; Zero or one trigger; One system name; One or many system responses.
The application of the EARS notation produces requirements in a small number of patterns, depending on the clauses that are used. The patterns are illustrated below.
1) Ubiquitous requirements
Ubiquitous requirements are always active (so there is no EARS keyword)
The <system name> shall <system response>
Example: The mobile phone shall have a mass of less than XX grams.
2) State driven requirements
领英推荐
State driven requirements are active as long as the specified state remains true and are denoted by the keyword While.
While <precondition(s)>, the <system name> shall <system response>
Example: While there is no card in the ATM, the ATM shall display “insert card to begin”.
3) Event driven requirements
Event driven requirements specify how a system must respond when a triggering event occurs and are denoted by the keyword When.
When <trigger>, the <system name> shall <system response>
Example: When “mute” is selected, the laptop shall suppress all audio output.
4) Optional feature requirements
Optional feature requirements apply in products or systems that include the specified feature and are denoted by the keyword Where.
Where <feature is included>, the <system name> shall <system response>
Example: Where the car has a sunroof, the car shall have a sunroof control panel on the driver door.
5) Unwanted behaviour requirements
Unwanted behaviour requirements are used to specify the required system response to undesired situations and are denoted by the keywords If and Then.
If <trigger>, then the <system name> shall <system response>
Example: If an invalid credit card number is entered, then the website shall display “please re-enter credit card details”.
6) Complex requirements
The simple building blocks of the EARS patterns described above can be combined to specify requirements for richer system behaviour. Requirements that include more than one EARS keyword are called Complex requirements.
While <precondition(s)>, When <trigger>, the <system name> shall <system response>
Example: While the aircraft is on ground, when reverse thrust is commanded, the engine control system shall enable reverse thrust.
Additional prompts:
<optional pre-condition> and <precondition(s)> fields are used to indicate a system / transaction state only (e.g. system is online, payment is processing, customer is logged in)
<optional trigger> and <trigger> fields are used to indicate a user operation or system event only (e.g. product selected, account created, product not available)
<system name> field always refers to the system, not a system actor or role (e.g. user / customer)
<system response> field always refers to what the system shall do (e.g. save account details, generate receipt) or comprise (e.g. technology component X)
<feature is included> field always refers to a an attribute or property of the system (e.g. system has capability Y system comprises technology component Z)
Draft 10 primary system functions for a "Customer Ordering System" component of an autonomous grocery delivery service (QuickCart). State each function as a verb-noun compound.
Translate these primary functions to EARs compliant requirements. Tabulate with following attributes : ID (REQ-0X), Requirement, EARS Type, rationale. Requirements should illustrate ubiquitous, state-driven and event-driven types.
I want you to verify these requirements according to the EARS ruleset. Tabulate with ID, Requirement, Type, Pass / Fail, Assessment attributes.
Senior Consultant, Managing Member at Wheatland Consulting, LLC.; Chair of the INCOSE Requirements Working Group (RWG).
2 年What is the EARS rule set that is being used? Just the format/template of the requirement statement? This will not result in well-formed requirement statements. To get well-formed requirement statements, the rules defined in the INCOSE Guide to Writing Requirements should be followed so that the requirements have the characteristics defined in the GtWR. I posted a reply to a previous post concerning my interaction with ChatGPT. My focus was asking ChatGPT to evaluate the quality of the requirements I gave it. ChatGPT responses were impressive. For those you list here, do the same and the responses are very good. In reality, what you show as requirements are really needs. The real requirements are what the system must do to meet those needs. When evaluated against the INCOSE GtWR, you will find it lists a lot of issues and recognizes these are very high level. The concept of needs vs requirements is an important concept that many are not comfortable with but has a lot of advantages.
Providing insightful solutions for requirements engineering
2 年As a part of a brainstorming excersize it seems like this format is a good way to get the output to be more consistent and consumable (as it does for human authors!) You mentioned the lack of Optional and Complex patterns in the output. Have you experimented much with generating Unwanted Behaviours? It seems like those will also be difficult for LLMs to properly classify. As an example, for a backup battery supply the sudden loss of power would be an expected “event” to respond to, but for many products it would be an “unwanted behaviour” to be mitigated. Not sure how common these situations would be.
Project Business Analyst | Operational Risk | Project Delivery | SE
2 年I'm impressed it correctly understood what REQ-02 was supposed to mean, but there is some ambiguity in the requirement. "While browsing products, the system shall display prices". While who was browsing products? It seems to refer to the system browsing the products.
Systems Thinker | Improvements Lead - BSc (Hons), CMgr FCMI, FICIPS, CSEP MINCOSE, CPRE IREB, AMBCS, APM-PMQ
2 年Lou W. Tami Katz Raymond Wolfgang Barclay R. Brown, Ph.D., ESEP James Carr Dr. John Malget ARCS MAPM MCMI FSaRS Alistair Mavin (Mav)