2. Academic Assumptions
ā¢ Effective software development
requires documented, precise,
complete requirements up-front.
ā¢ Such requirements must remain
up-to-date all along development,
up to deployment, and after that
during system evolution.
ā¢ That sounds logical to many.
(except agile folks), and drives
(most of) academic research.
2
3. Quotes from Practice
ā¢ āFor many applications a highly detailed technical specification is just too
much up front since a quick discussion could render their carefully
typeset document useless. Instead, start with a vision. If everyone
understands the overall picture then the requirements can get filled in
along the way through discussions.ā
ā¢ āSteve Jobs believed that customers cannot describe exactly what they
want the future products to look like, so it is your job to deliver them. So,
unless you deliver custom software all the time, forget formal specs and
start by creating prototypesā¦ā
ā¢ āUnless youāre building something to a specification, you usually only
have a vague idea of what the final product should look like at the time
you start a project.ā
3
4. State of Practice
ā¢ In practice resources and time are limited,
uncertainty about requirements is high
ā¢ Trade-offs are unavoidable
ā¢ Often, requirements are subject to such trade-
offs, leading to imprecise, incomplete, or
obsolete (documented) requirements
ā¢ Diversity: āRE practice differs according to the
types of organization developing software, the
types of products being developed, and the
particular application domain of the product. ā
(Lui et al. 2010)
4
5. Special Situations
ā¢ Requirements serve as a contract, to
be validated during acceptance testing
ā¢ Requirements traceability is required
by standards or regulations, e.g.,
safety critical systems
ā¢ Even then, the precision and
completeness of requirements are
often elusive goals
ā¢ The goal is only to achieve
certification/regulatory compliance
5
Enterprise Architect
Sparx Systems
6. Challenges: Liu et al. (2010)
ā¢ Customers do not have a clear understanding of system requirements
themselves, including scope of the system, major functional features and
nonfunctional attributes.
ā¢ Usersā needs and understanding constantly change.
ā¢ Project schedule is too tight to allow sufficient interaction and learning
period between customer and development team.
ā¢ Broken communication links between customer, analyst and developer.
6
Liu et al., āWhy Requirements Engineering Fails: A Survey Report from Chinaā, IEEE RE 2010
7. Recommendations: Liu et al.
ā¢ Link requirements with testing and adopt a test-driven design
process.
ā¢ Develop RE tools that better fit the real-world needs of the
customers and engineers.
7
8. Challenges: Martins and
Gorschek (2020)
ā¢ Focus on safety-critical systems, where precise and complete requirements are
expected to be most common.
ā¢ All companies write their requirements documents in natural language. UML
diagrams and other types of diagrams (as FTA and flowchart) are seldom used to
describe the requirements.
ā¢ Two companies used āformal methodsā, but not from software engineering:
Equations from control engineering
ā¢ 61% use word processing and spreadsheets as RE tools
8
Martins and Gorschek, āRequirements Engineering for Safety-Critical Systems:
An Interview Study with Industry Practitionersā, IEEE TSE 2020
9. Challenges: Martins and
Gorschek (2020)
ā¢ āWhen someone does not understand a requirement a person conversation is
performed, usually people go to the team leader, systems engineers or safety
engineer to get the understanding. This is done in an informal way.ā
ā¢ āPractitioners from three companies mentioned that somehow it is necessary to
produce more useful documents in order to meet the daily needs of the system
developers. It seems that the requirements documents still are more to show
compliance than to be really used by development teams.ā
ā¢ āThe designers and programmers know what to do, of course the requirements
specification is there to drive it, but in details it is very common that the
requirements donāt really drive the designers/programmers.ā
9
10. Factors Affecting Practice
ā¢ Lack of skills, training (often invoked by academics)
ā¢ Frequent requirements changes, uncertainty
ā¢ Time pressure, lack of resources
ā¢ Lack of adequate tool support and automation
ā¢ Result: Low return on investment (RoI) for precise, complete
requirements (real or perceived?)
10
11. Widespread Situation
ā¢ Informal, natural language requirements
ā¢ Sometimes completed with informal diagrams (UML, SysML
ā¦)
ā¢ Quality (precision, completeness, ā¦) is relatively low
11
12. My Take
ā¢ Higher RoI for precise requirements would require effective
support for:
ā¢ Quality assurance
ā¢ Change management
ā¢ Traceability (e.g., to systems tests)
ā¢ Example projects next
12
15. Requirements QA
ā¢ Manual QA is expensive and tedious
ā¢ Especially in the context of frequent changes
ā¢ No systematic feedback
ā¢ Leads to low quality requirements
ā¢ Example project in the financial domain
15
16. Industrial Context and Artifacts
ā¢ Global leading supplier of post-trading services
ā¢ 2500 customers in 110 countries
ā¢ Compliance with financial regulations
ā¢ Loosely follows the Rupp template
ā¢ 13 Software Requirements Specifications (SRS)
ā¢ 2725 requirements
ā¢ Written by different business analysts
ā¢ Relatively low quality, not used for validation
16
17. Controlled Natural Language:
Rimay
ā¢ Strike a balance between the usability of NL and the rigor of formal languages
ā¢ More specialized concepts and constructs than conventional templates
ā¢ Qualitative analysis
ā¢ Evaluation
17
REQUIREMENT: SCOPE? CONDITION_STRUCTURE?
ARTICLE? ACTOR MODAL_VERB not? SYSTEM_RESPONSE.
SCOPE: For MODIFIER? TEXT (and MODIFIER? TEXT),
SYSTEM RESPONSE: VALIDATE | ... 47 action phrases
Actor
Scope
For each "line of the File", System must
check that Share_Class_Identifier.Value contains "line.ISINā.
Modal Verb
System Response
Veziaga et al., āOn systematically building a controlled natural language for
functional requirements.ā, Empir. Softw. Eng. 26(4): 79 (2021)
18. Quality Attributes
18
ā¢ Quality attributes enforced by Rimay
ā¢ Completeness: Presence of all the information required for the
requirement to be complete
ā¢ Correctness: Presence of correct information content in the correct
order of appearance
ā¢ Clarity: Usage of structures, phrases, and words that are free of
ambiguity
ā¢ Atomic requirements: A requirement with a single system function
19. Smells
ā¢ 10 smells: ā1. Non atomicā, ā2. Incomplete requirementā, ā3. Incorrect order
requirementā, ā4. Coordination ambiguityā, ā5. Not requirementā, ā6. Incomplete
conditionā, ā7. Incomplete system responseā, ā8. Incomplete scopeā, ā9. Passive
voiceā, and ā10. Not precise verbā
19
When creating a new participant,
System-A must open in edit mode the detail participant screen.
System Response
Condition (Missing Actor)
When a settlement request has reached the status āSettledā
then System-A must sed the settlement request to System-B.
System Response (No verb)
Condition
20. Rimay Patterns
20
Requirement
Condition_Structure Modal_Verb Action_Phrase
If_Structure ā¦
Actor
Precondition
0..*
1..*
1
1 1..*
+System_Response
ā¢ Excerpt of the Rimay conceptual model:
ā¢ Example:
Condition_Structure (Precondition)
If Inx.description contains a "Keywordā, System-A must forward Inx to System-B.
Actor Modal_Verb System_Response (Action_Phrase)
21. Rimay Patterns
ā¢ 10 Rimay patterns: āļ»æ1. Scope and system responseā, āļ»æ2. Scope, condition
(precondition), and system responseā, āļ»æ3. Scope, condition(Trigger), and
system responseā, āļ»æ4. Scope, condition (Time) and system responseā, ā5.
System responseā, āļ»æ6. Condition(Precondition), and system responseā,
āļ»æ7. Condition(Trigger), and system responseā, āļ»æ8. Condition (Time) and
system responseā, āļ»æ9. Scope, multiple conditions, and system responseā,
āļ»æ10. Multiple conditions, and system responseā
ā¢ Pattern Name: System response
ā¢ Rimay Pattern: The? Actor must <Action> (every "Text")?
ā¢ Example: The System-A must link "allegement message-A" to the
"outgoing message-123"
21
22. QA Approach: Paska
1. Apply preprocessing
steps to requirements
2. Divide requirements into
scope, condition and
system response
3. Identify smells present in
requirements
4. Suggest a Rimay pattern
to fix detected smells
22
Preprocess Requirements
1
Identify Smells
3 Suggest Rimay Patterns
Separate Requirements
into Segments
4
2
+
Rimay
patterns
Requirements
with smells
Rimay
Patterns
Requirements
Specifications
Smells
For each āline of the Fileā,
System must check that Share_CLass_Identifier.Value
contains āline.ISINā.
When Transfer_System receives a File,
Transfer_System must forward the File to System.
For each āline of the Fileā,
System must check that Share_CLass_Identifier.Value
contains āline.ISINā.
When Transfer_System receives a File,
Transfer_System must forward the File to System.
Veziaga et al., āAutomated Smell Detection and Recommendation in
Natural Language Requirements.ā, IEEE TSE (2024)
23. Paska: Evaluation
ā¢ Evaluation on unseen SRSs
ā¢ Many instances of smells
ā¢ Overall precision and recall of 89% in detecting smells
ā¢ Overall precision of 96% and recall of 94% in suggesting Rimay patterns
ā¢ Based on the pattern it is straightforward to fix a requirement
ā¢ Promising tool for automated QA of natural language requirements for
information systems
23
25. Acceptance Testing
ā¢ Acceptance testing from requirements
ā¢ Systematically Identifying and designing test scenarios
ā¢ Overcome biases and blind spots
ā¢ Traceability requirements ā system tests often required
25
26. Test Cases from Use Cases
ā¢ Test case descriptions from use case descriptions
ā¢ Use case specifications are common and operational
representations of requirements
ā¢ Manual and laborious task
ā¢ Context: Automotive software.
ā¢ Use cases were a basis for contractual agreements
ā¢ Automation based on NLP: UMTG
26
27. Use Case
Specifications
(RUCM)
Executable Test Cases
Constraints capturing
the meaning of
conditions
Domain
Model
UMTG
Error.allInstances()
->forAll( i | i.isDetected = false)
UMTG
https://sntsvv.github.io/UMTG/
Wang et al., āAutomatic Generation of Acceptance
Test Cases From Use Case Specifications: An NLP-
Based Approachā, IEEE TSE, 2020
28. ā¢ Restricted Use Case Modeling (RUCM)
ā¢ Experiments shows it yields better use cases
ā¢ Compliance is tool-supported (NLP)
ā¢ More analyzable with NLP
Yue et al., ACM TOSEM 2013
Restricted Use Case
Specifications
28
29. RUCM Specifications Example
Precondition: The system has been initialized
Basic Flow
1. The SeatSensor SENDS the weight TO the system.
2. INCLUDE USE CASE Self Diagnosis.
3. The system VALIDATES THAT no error has been detected.
4. The system VALIDATES THAT the weight is above 20 Kg.
5. The system sets the occupancy status to adult.
6. The system SENDS the occupancy status TO AirbagControlUnit.
INPUT STEP
INCLUDE STEP
CONDITIONAL STEP
INTERNAL STEP
OUTPUT STEP
Alternative Flow
RFS 4.
1. IF the weight is above 1 Kg THEN
2. The system sets the occupancy status to child.
3. ā¦
4. RESUME STEP 6. 29
31. UMTG: Empirical Evaluation
ā¢ It is hard for engineers to capture all the possible scenarios
involving error conditions. UMTG covers them.
ā¢ 5 to 10 minutes to write each constraints (but we also
developed a tool to generate them)
ā¢ 10 secs/test case using a constraint solver based on Alloy
ā¢ Less than 10 minutes in total to generate all system test cases
(54)
35
33. Traceability
ā¢ The ability to follow the life of software artifacts, in both a backward and
forward direction, e.g., requirements, design decisions, test cases.
ā¢ Requirements traceability: Trace a requirement from its emergence to its
fulfillment, e.g., acceptance test cases.
ā¢ Motivations:
ā¢ Understand rationale
ā¢ Certification, auditing, compliance with standards
ā¢ Assess impact of change
37
34. Traceability between
Requirements
ā¢ Natural language
ā¢ Sometimes structured (template)
ā¢ Hundreds of traces
ā¢ Domain terminology, concepts, and their relationships are key
to discovering traces among requirements
ā¢ Rely on syntactic and semantic similarity measures
38
Requirements
36. Example
ā¢ R1: The mission operation controller shall transmit satellite
status reports to the user help desk.
ā¢ R2: The satellite management system shall provide users with
the ability to transfer maintenance and service plans to the
user help desk.
ā¢ R3: The mission operation controller shall transmit any
detected anomalies with the user help desk.
40
37. Change Example
ā¢ R1: The mission operation controller shall transmit satellite
status reports to the user help desk document repository.
ā¢ R2: The satellite management system shall provide users with
the ability to transfer maintenance and service plans to the
user help desk.
ā¢ R3: The mission operation controller shall transmit any
detected anomalies with the user help desk.
41
38. Challenge#1 -
Capture Changes Precisely
ā¢ R1: The mission operation controller shall transmit satellite
status reports to the user help desk document repository.
ā¢ R2: The satellite management system shall provide users with
the ability to transfer maintenance and service plans to the
user help desk.
ā¢ R3: The mission operation controller shall transmit any
detected anomalies with the user help desk.
42
39. Challenge#2 -
Capture Change Rationale
ā¢ R1: The mission operation controller shall transmit satellite
status reports to the user help desk document repository.
ā¢ R2: The satellite management system shall provide users with
the ability to transfer maintenance and service plans to the
user help desk.
ā¢ R3: The mission operation controller shall transmit any
detected anomalies with the user help desk.
43
40. ā¢ R1: The mission operation controller shall transmit satellite status reports to the user help desk
document repository.
ā¢ R2: The satellite management system shall provide users with the ability to transfer
maintenance and service plans to the user help desk.
ā¢ R3: The mission operation controller shall transmit any detected anomalies with the user help
desk.
44
Challenge#2 -
Change Rationale
Rationales:
1: We want to globally rename āuser help deskā
2: Avoid communication between āmission
operation controllerā and āuser help deskā
3: We no longer want to ātransmit satellite status
reportsā to āuser help deskā but instead to āuser
document repositoryā
41. Solution Characteristics
ā¢ Accounts for the phrasal structure of requirements
45
The mission operation controller shall transmit satellite
status reports to the user help desk document repository.
user help desk, Deleted
user document repository, Added
ā¢ Account for semantically-related phrases that are not exact
matches and close syntactic variations
42. Approach
46
Arora et al., āChange Impact Analysis for Natural
Language Requirements: An NLP Approachā,
IEEE RE, 2015
43. Approach
47
Rationale:
Avoid communication between mission operation
controller and user help desk.
Propagation condition:
mission operation controller AND user help desk
AND transmit
Arora et al., āChange Impact Analysis for Natural
Language Requirements: An NLP Approachā,
IEEE RE, 2015
44. How effective is our approach?
ā¢ Extra requirements traversed
ā¢ Case-A between 1%-7%
ā¢ Case-B between 6%-8%
except one case
ā¢ Number of impacted
requirements missed:
1 out of 106
48
46. Requirements-Design
Traceability
ā¢ Capture the rationale of design decisions
ā¢ Support evolution, avoid violating essential design decisions
ā¢ Useful for impact analysis based on traces
ā¢ What is a rationale? Level of granularity?
ā¢ Design representation?
50
Archi. & Design
Requirements
47. System Design Modeling
ā¢ Systems Modeling Language (SysML)
ā¢ A subset of UML extended with systems engineering
diagrams
ā¢ A standard for systems engineering
ā¢ Preliminary support for requirement analysis and built-in
traceability mechanism
51
48. CIA Automation Goal
ā¢ Given a change in a requirement, our goal is to compute a set
of (potentially) impacted design elements that includes
ā¢ all the actually impacted elements (high recall)
ā¢ very few non-impacted elements (high precision)
52
51. :Over-Temperature
Monitor
:Diagnostics
Manager
:Diagnostics and
Status Signal
Generation
:Digital to Analog
Converter
:DC Motor
Controller
:Temperature
Processor
<<requirement>>
Over-Temperature
Detection
(R11)
<<requirement>>
Operational
Temperature Range
(R12)
B1
B2
B3
B4
B5
B6
<<satisfy>>
<<satisfy>>
Internal Block Diagrams (IBD)
ā¢ IBDs contain SW and HW blocks, ports,
connector relations between ports, plus
Satisfy traceability links between
requirements and blocks.
ā¢ A satisfy link between a block and a
requirement indicates that the function
implemented by the block contributes to
the satisfaction of the requirement.
52. Diagnostics Manager
<<Decision>>
Is position valid?
<<Decision>>
Over-Temperature
detected?
<<Assignment>>
Error = 1
B3
<<Assignment>>
MotorDriveMode = OFF
<<Assignment>>
MotorDriveMode = RUN
[yes] [no]
[yes]
[no]
Activity Diagrams (AD)
53. Traceability Information Model
58
Requirements
Structure
Requirement
Block
Software block
Port
Activity diagram
satisfy
*
* origin
target
*
Out
Hardware block
behaviour
Transition
Node
1..* Action
Object
Control Object Call
Assignment
Parameter
Local
In
source
1..*
Decision
target
*
1 1
connector
Behaviour
Software
requirement
Hardware
requirement
in
out
correspond
Data
Control
1..*
*
*
1
1
*
Explicit
traceability links
56. Case Study
61
Electronic Variable Cam Phaser (CP)
ā¢ Includes mechanical,
electronic and software
components
ā¢ Adjusts the timing of cam
lobes with respect to that
of the crank shaft in an
engine, while the engine is
running.
ā¢ CP is safety-critical and
subject to the ISO 26262
standard.
57. Summary
ā¢ We provided an approach to automatically identify the impact of requirements changes
on system design
ā¢ Our approach includes:
ā¢ A SysML modeling methodology with acceptable traceability cost
ā¢ An algorithm for impact computation that combines modelsā structure, behavior and
textual information
ā¢ Industrial case study: Our hybrid approach reduces the number of elements inspected
from 370 to 18
ā¢ Scalable approach: A few seconds to compute and rank estimated impacted elements
65
59. Main Takeaway Message
ā¢ In most cases, for many reasons, providing guidance to
architects and developers does not seem to be a sufficient
motivation to document requirements in a precise and
complete form.
ā¢ We somehow need to increase the RoI of writing such
requirements if we want practice to change.
ā¢ We need to develop practical technologies that increase RoI
68
60. A Way Forward
ā¢ Many opportunities: (1) Acceptance test automation, (2)
Change impact analysis (e.g., for safety certification or
regulatory compliance), (3) Automated QA, and more.
ā¢ With a focus on natural language requirements.
ā¢ With a high degree of robustness to unrestricted, flawed NL
requirements
ā¢ Keeping in mind scalability
69
61. Requirements for AI Systems
ā¢ No source code from which to derive intent
ā¢ Components for which precise functional requirements are difficult
to express, e.g., pedestrian detection
ā¢ Safety, robustness, and security requirements are critical though --
- their specification will increasingly be required by regulations
ā¢ Operational Design domain must be specified (a form of
requirement)
ā¢ There is an opportunity for impact here for the RE community!
70
62. Operational Design Domain
ā¢ An operational Design Domain (ODD) refers to the specific conditions under
which a system or technology, like an Autonomous Vehicle (AV), is designed
to function safely and efficiently.
An ODD includes characteristics such as:
ā¢ Geographic location: roads, highways, or regions where the system is intended
to operate.
ā¢ Environmental conditions: weather and light conditions such as daytime,
nighttime, fog, rain, or snow.
ā¢ Traffic conditions: types of other road users (vehicles, pedestrians, cyclists),
traffic density, and road infrastructure.
ā¢ Operational constraints: legal restrictions, speed limits, or other rules that the
system must adhere to
71
63. LLMs in Requirements
Engineering
ā¢ Requirements generation
ā¢ Requirements completion
ā¢ Requirements to test cases
ā¢ Requirements classification
ā¢ ā¦
ā¢ May render automation more
affordable and practical
72
LLMs for NLP Tasks in RE: A Systematic Guide 11
LLMs like T5 are specialized for text-to-text translation. In the following, we
will explain these usage modes in detail.
Decoder-only
LLM
Task Model
Encoder-only
LLM
Using
Decoder-only
LLMs
Using
Encoder-only
LLMs
Embedding
Input Output
Prompt Output
Encoder-
Decoder LLM
Using
Encoder-
Decoder
LLMs
Input Output
Fig. 2. Simplified overview of using different LLM architectures to solve tasks
3.3 Using Encoder-only LLMs
Fig. 3 shows potential pipelines using the LLMs as language embedders. In this
usage mode, a specific RE task is solved by leveraging the semantically rich em-
beddings generated by an LLM. In contrast to simpler embedding techniques
like tf-idf or bag-of-words, LLM embeddings better capture the meaning of a
word in its context (see Section 2.1). The embeddings are then used in specific
Vogelsang and Fishbach, āUsing Large Language
Models for Natural Language Processing Tasks in
Requirements Engineering: A Systematic Guidelineā,
ArXiv, 2024
65. SyMeCo Fellowship
ā¢ SyMeCo is a Marie SkÅodowska-Curie postdoctoral fellowship
programme coordinated by Lero
ā¢ Co-funded by Science Foundation Ireland and the EU
ā¢ 16 fellowships of 2-year duration based in Ireland across 8
Higher Education Institutions
ā¢ Open to researchers of any nationality