1. Tao Yue and Shaukat Ali Simula Research Laboratory Nov. 1st, 2016
SECM - Requirements Concepts Initial proposal on restricted textual requirement
Tao Yue and Shaukat Ali
Simula Research Laboratory
Nov. 1st, 2016

2. Boeing practice – from Ronald S. Carson
Classified requirements into four types:
Functional/Performance requirements, Design requirements, Environmental requirements, and Suitability requirements
Patterns
General pattern:
The agent shall what, how well, under what conditions.
Specific patterns:
Functional/Performance requirements
The AGENT shall FUNCTION in accordance with INTERFACE-OUTPUT with PERFORMANCE [and TIMING upon EVENT TRIGGER in accordance with INTERFACE-INPUT] while in CONDITION.
Environmental requirements:
The AGENT shall exhibit CHARACTERISTIC with PERFORMANCE while CONDITION [for CONDITION DURATION].
Measuring Requirements Quality for Verifiability
An editor and the measurement have been implemented in DOORS.
Carson et al. filed a US patent on this topic.
Simula Research Laboratory

3. Requirements patterns from INCOSE and ISO/IEC/IEEE 29148:2011
The <subject clause> shall <action verb clause><object clause><optional qualifying clause>, when <condition clause>
ISO/IEC/IEEE 29148:2011
[condition][subject][action][object][constraint]
Simula Research Laboratory

4. Restricted Use case Modeling (rucm)
Keywords
Conditional logic sentences
IF-THEN-ELSE-ELSEIF-ENDIF
Concurrency sentences
MEANWHILE
Iteration sentences
DO-UNTIL
Conditional checking sentences
VALIDATES THAT
Other keywords specific to use case modeling
Sentences structures
Parts of speech (POS) are automatically obtained by using Natural Language Processing techniques.
RUCM requirements can be automatically formalized if needed.
Simula Research Laboratory

5. Summary of existing solutions
Criterion
Boeing Practice
INCOSE
ISO/IEC/IEEE 29148
RUCM
Requirements Structure/Patterns
Yes (enforced)
Sentences
Yes
Yes (partially)
Sentences and cross sentences
Keywords No
Transformation to more formal specification
Yes, natural language processing (NLP) techniques help to relax restrictions on requirements structures/patterns, help to formalize requirements, and eventually help to generate other artifacts.
The question is:
Do we enforce sentence structures? If yes, how much do we enforce? People can rely on NLP techniques to obtain sentence structures.
Enforcing requirements structures with an acceptable extent and combining it with keywords (IF-THEN..) might be a good option.
Candidate solutions for restricted requirements specifications
Keywords + NLP
Patterns + Keywords
Patterns + Keywords + NLP
With all the three above, transformations to other artifacts can be enabled to various extents.
Simula Research Laboratory

6. Restricted Textual Requirements
Suggested keywords to use:
REALIZE
IS GREATER THAN, LESS THAN, EQUAL TO, etc.
We have defined a list of such keywords for iOCL.
IF-THEN-ELSE-ELSEIF-THEN-ENDIF, DO UNTIL, MEANWHILE, VALIDATES THAT
RUCM has a list of keywords defined for conditions, iteration and concurrency
INCLUDE, EXTENDED BY
Example
Input
“IF the boiler water temperature [ContextProperty] IS GREATER THAN the Boiler Water Valve Threshold of 85oC [ContextProperty], THEN Actual Inlet Valve Control Behavior [ConstrainedProperty] of Control Subsystem shall REALIZE INCLUDE Inlet Valve Control Function [ConstrainingProperty] to open the inlet valve [RealizedElement], ELSE close the inlet valve [RealizedElement] ENDIF.”
Output
List of properties
IF Boiler Water Temperature > Boiler Water Threshold, THEN Open Inlet Valve, ELSE Close Inlet Valve ENDIF.
With this constraint, a Realize Evaluation can be generated automatically when needed.
Do we need to formalize Open Inlet Valve and Close Inlet Valve?

7. Restricted Textual Requirements
Several questions
Is Inlet Valve an realized element?
Does the activity diagram specifying Inlet Valve Control Function at the requirements level or design?
We might need templates to enforce structures if requirements are complicated.
Going from restricted textual requirement statements to formal requirement statements
(Semi-automatically) Extract properties from noun phrases (one heuristic)
Automatically extract constraints.

8. Suggested Conceptual Model Changes
Question to answer: keep Restricted Requirement Statement or merge with Formal Requirement Statement?
Partial answer to this question:
Restricted Requirement Statements (RRS) are created by using specific methodologies (e.g., req. structure/pattern based, and/or keyword-based), which aim for reducing ambiguity, therefore improving quality of requirements, and enabling automated analyses and generation of other artifacts.
RRS might need to be distinguished from Formal Requirement Statement (FRS), which is more like property-based.
FRS can be more easily associated to the system design and constraints can be more easily formalized at this stage.
The gap between RRS and FRS can be bridged if needed, with automated solutions.
Depending on specific methodologies, RRS and FRS can all be optional.
One thing to notice that: all the concepts related to Sentence can be automatically populated.

9. Methodologies
Manual free textual requirements statements and manual formal requirements statements
Manual restricted textual requirements statements and automated (mostly) formal requirements statements
Manual restricted textual requirements statements and automatically generated UML diagrams (e.g., activity diagrams)

10. Transformations Input: Restricted requirement statements
Output 1: Formal requirement statement
Output 2: SysML analysis or design diagrams
Output 3: other artifacts such as tests

11. Small Demo

12. Small Demo