Systematic research of
Combinatorial Effects at
Requirements Engineering Level
Jan Verelst
Alberto Rodrigues Silva
Herwig Mannaert
David Almeida Ferreira
Philip Huysmans
Overview
• Introduction
• Normalized Systems Theory
• Identifying Combinatorial Effects
-
BPMN
UML Use Cases
“Real World”
UML Domain Models
DEMO/EO
• Conclusions
• Research agenda
1
Introduction
• The origin: Sabbatical Alberto Silva, specialized in
Requirements Engineering (RE)
• The idea: to apply Normalized Systems Theory (NS) to RE.
Can RE be considered in terms of modular structures ? Or is
this too technical and therefore inappropriate ?
- Jorge Sanz’ talk: bring EE to mainstream management !
- “Together with communications theory-based approaches, such
as DEMO, this would suggest that the real world is first and
foremost an area of human behavior, which should therefore
not predominantly be studied by theories based on computer
science and/or automation. We agree with this point of view.
Nevertheless, in modern society, human behavior
increasingly takes place in highly structured, processbased contexts. Therefore, we argue that it is relevant to study
these aspects of reality based on concepts such as modularity,
while at the same time making an abstraction from purely
human and communication aspects.”
2
Software Requirements Specs
• Software Requirements Specification (SRS)
- A requirements specification is used throughout different
stages of the project life-cycle, namely to help sharing the
system vision among the main stakeholders, as well as to
facilitate their communication, the overall project
management, and system development processes.
• Benefits
- Establishes the basis for agreement between the
customers and the suppliers on what the system is
expected to do;
- reduces development efforts;
- provides a basis for estimating costs and schedules;
- provides a baseline for verification and validation;
facilitates the system deployment;and
- serves as a basis for future maintenance activities
3
Business and System Level
•
•
Business level
-
Constructs
-
Languages/Models
•
Terminology, goals, stakeholders, business processes, business use cases
•
Goal-oriented languages (i*, KAOS), UML, BPMN, RUP Business Modeling, DEMO/EO, Archimate
System level
-
-
-
-
Context models
•
Constructs
•
Languages
-
System, subsystem, componenents, nodes, external actors
SysML Block Diagrams, UML Deployment Diagrams, Data Flow Diagrams
Domain Models
•
Constructs
•
Languages
-
Entities, classes, …
UML Class Diagrams, Entity Relationship Diagrams
Functional requirements models
•
Constructs
•
Languages
-
Actors, functional requirements, use cases, scenario’s, user stories
Natural language enriched with metadata (priority, risk levels…), UML Use Case diagrams, SysML
Requirements Diagrams
Quality attribute models
•
Constructs
•
Languages/Models
-
Qualities, metrics, utility values,
lists of quality attributes, quality-attributes scenario’s
4
Why study CE at RE-level ?
• In theory
- The importance of evolvability in RE is sometimes
overlooked
• OO: anthropomorphism
•  Simsion et al.: analysis = creative design activity
• In practice
- Inability to evolve may lead to misalignments
between requirements and information systems
• Requirements often constitute documentation => out-ofdate
- RE requires considerable resources => inefficient
5
About NS Theory
• A theoretical framework investigating Modular
Structures under Change
- Based on Systems Theoretic concepts
•  Completely independent of any framework, programming language,
package, …
• Has shown to be able to deal with the challenge of increasing complexity
-
E.g. hardware, Internet, space industry…
- Initial scope: Modular Structures in Software Architectures
- Publications: book, >50 conference proceedings, (invited)
lectures at different universities…
- Education: undergraduate, postgraduate…
6
NS @ software level
Struct
Func
Struct Customer
- Name
- Address
- VATnr
-…
Func computeInvoice
Struct Invoice
- Nr
- Date
-…
Func inviteCustomer
IMPACT
IMPACT
IMPACT
Func sendInvoice
N
IMPACT N
7
NS Principles
• Modularity x Change  Combinatorial Effects (CE) !
- CE = (hidden) coupling or dependencies, increasing with
size of the system !
- NS Principles identify CE at seemingly orthogonal levels
• SoC: Which tasks do you combine in a single module ?
-
“An action entity can only contain a single task.”
-
“Data entities that are received as input or produced as output by action entities,
need to exhibit version transparency.”
• DVT: How do you combine a data and action module ?
• AVT: How do you combine 2 modules ?
-
“Action entities that are called by other action entities, need to exhibit version
transparency.”
• SoS: How do you combine modules in a workflow ?
-
“The calling of an action entity by another action entity needs to exhibit state
keeping.”
• CE explain Lehman’s Law of Increasing Complexity !
8
NS Summary
Current Practice
1. Modularity
- Combinatorial Eff.
- White-box reuse
- Lehman
2. Standardization
- No expansion
Assumption:
Modular Structures:
Complexity ↑
X
Change ↑
NS-Determinism
1. Modularity
- No Combinatorial Eff.
- Black box reuse
- Lehman controlled
2. Standardization
- Expansion
Fine-grained/
No Combinatorial Eff.
Expansion
Lehman
Black-box reuse/
Lehman controlled
9
NS as a simple transformation
over F/C gap
Tasks
computeInvoice
inviteCustomer
F
Data
Customer
-Name
-Address
-VATnr
…
Struct
Struct Customer
- Name
- Address
- VATnr
-…
C
Func
Func computeInvoice
sendInvoice
Invoice
-Nr
-Date
-…
Struct Invoice
- Nr
- Date
-…
Func sendInvoice
Func inviteCustomer
IMPACT
Change:
addAttribute
IMPACT
IMPACT
N
IMPACT N
10
The concern trapezoid
Examples of concerns:
“Want innovative invoicing”
Business
F
Concerns are additive (?)

#concerns ↑↑
High-level business
- Strategy (innovation vs cost)
- Internationalisation
High-level ICT
- Stick with current package
- Commodity ICT
Human
- Stakeholder issues (political…)
- Communication, negotiation
C
Examples of concerns:
Low level ICT:
- Performance of an algorithm or call to package
- Interface stability
- Internationalisation libraries present
- Technical security details
- …
ICT
13
Bridging a F/C gap
• An ill-structured (or wicked) design problem
- Incomplete and ambiguous specification of the problem;
- No deterministic path to solution;
- Knowledge of several domains needs to be integrated in
order to find a solution;
- No clear criteria te compare and evaluate possible
solutions.
• Characteristics
- M:N, not 1:1
- Integration = Fragile/Non-lineair behavior: 5% extra
reliability  totally different architecture
- Integration = sometimes all-or-nothing
• ALL concerns need to be separated at compile/deploy/runtime, or the
remaining coupling
- May make the artifact totally useless in practice !
- Solving this requires a white box-perspective without complexity
reduction !
14
NS as a complex transformation
over F/C gap
Tasks
computeInvoice
F
inviteCustomer
Customer
-Name
-Address
-VATnr
…
Data
sendInvoice
Invoice
-Nr
-Date
-…
Change:
addAttribute
IMPACT
Data
Elements
Customer
Element
Invoice
Element
C
IMPACT
IMPACT
Action
Elements
compute
Invoice
Element
invite
Customer
Element
send
Invoice
Element
15
Enterprise = n F/C gaps
Strategy
RW
F
DEMO/EO
Use Cases
Domain Models
C
PPM/EA
F
C
PM
F
C
RE/Analysis
F (Alberto Silva’s group)
C
Design
F
BPMN
Implementation
Increasing
modular
structure
NS @ Enterprise=
Normalized
Transformation
Over the
F/C gaps
NS@
Software
C
Maintenance
25
Enterprise = n F/C gaps
Strategy
RW
PPM/EA
DEMO/EO
PM
Use Cases
Domain Models
NS @ Enterprise=
Normalized
Transformation
Over the
F/C gaps
RE/Analysis
(Alberto Silva’s group)
Design
BPMN
NS@
Software
Implementation
Increasing
modular
structure
Maintenance
26
BPMN models
BPMNcreateExpenseReimbursement
28
BPMN
Real World
createExpenseReimbursement
Real World
createBonusPayment
F
N
Change:
checkAccountExistence is shared
createExpenseReimbursement
checkAccountExistence v2
createBonusPayment
N
C
BPMN Task
IMPACT
IMPACT
IMPACT N
29
BPMN-with separated Task
F
Real World
createExpenseReimbursement
Real World
createBonusPayment
N
Change:
checkAccountExistence is shared
createExpenseReimbursement
C
checkAccountExistence v2
createBonusPayment
N
checkAccountExistence
Remark:this is NOT
an NS element !
BPMN Task
IMPACT
30
BPMN
• PhD Dieter Van Nuffel contains examples of CE
regarding SoC and 25 guidelines to eliminate them
• Modular structure ?
- “Easy, obvious !”
- Constructs ?
• All BPMN constructs…
- CE ?
• Violations of SoC, SoS may occur
• application of AvT and Dvt is less clear
• Implications
- Evolvability of BP is limited
•  popular claim of BPM-engines, even though they do add
evolvability at the software-level !
31
UML Use Cases
UML Use Cases
Use Case
createExpenseReimbursement
3. checkAccountExistence
4. createAccount
…
7. reimburse
Use Case
createBonusPayment
3. checkAccountExistence
4. createAccount
5. executePayment
33
UML Use Cases
Real World
Interviews (oral)
Interview transcripts
F
Change:
checkAccountExistence v2
createExpenseReimbursement
createBonusPayment
N
C
Use Cases
IMPACT
IMPACT
IMPACT N
34
UML Use Caseswith hypertext construct
Real World
Interviews (oral)
Interview transcripts
F
checkAccountExistence v2
createExpenseReimbursement
C
Change:
N
createBonusPayment
checkAccountExistence
Remark:this is NOT
an NS element !
Use Cases
IMPACT
35
Use Cases
• Modular structure ?
-
Constructs ?
• YES
-
• NO
-
-
Name of the use case => primitive interface of the module
Pre- and post-conditions => delineate functionality of the module
Workflow (tekst) => functionality details of the module
Other: A scenario, an exception, a trigger, a stakeholder, …
Text-based use cases allow for GOTO’s, ambiguities…
Hypertext construct not always available in tooling !
CE ?
• Use cases are usually too underspecified to allow detailed analysis of CE
• Violations of SoC may occur
• application of AvT and Dvt is less clear: do use cases have interfaces ?
• Implications
-
Evolvability of Use Cases is limited
• This is a well-known issue, particularly in large projects,
-
Maintaining documentation becomes expensive
Use Cases does not necessarily document the code (when the code itself is changed)
36
Real World
Example 1:
createExpenseReimbursement
Real World
Interviews (oral)
Interview transcripts
F
C
Manually
Executed
BP & IS (=paper)
Change:
checkAccountExistence v2:
“Use NL bank only from now !”
Actor 1:
createExpenseReimbursement
IMPACT
Actor 2:
createBonusPayment
IMPACT
N
IMPACT N
38
Example 1:
createExpenseReimbursement
• This example can be 100% manual !
• Modular structure ?
- Constructs ?
• Human actors executing formal/informal procedures
- CE ?
• Visible at runtime (resources): Violation of SoC ?
39
Example 2: Exam Marks
Real World
Procedure: ‘our university
applies … rounding’
F
Professor 1
Professor 2
Change:
Procedure v2
N
C
Decentralized
Execution of
BP & IS
IMPACT
IMPACT
IMPACT N
40
Example 2: Exam Marks
• Modular structure ?
- Constructs ?
• Human actors executing formal/informal procedures
- CE ?
• Visible at runtime (resources): Violation of SoC ?
41
Example 2: Exam Marks –
Compile Time Model
F
C
Decentralized
Execution of
BP & IS
Real World
Procedure: ‘our university
applies … rounding’
Procedure
Executed
by all Professors
Change:
Procedure v2
N
INVISIBLE
IMPACT !!!
42
Example 2: Exam Marks
F
C
Centralized
Execution of
BP & IS
Real World
Procedure: ‘our university
applies … rounding’
Change:
Procedure v2
Student
Office
IMPACT
43
Example 3: Mail distribution
Real World
Procedure: ‘our university
allows physical mail’
F
Secretary 1
Secretary 2
Change:
Procedure v2
N
C
Decentralized
Execution of
BP & IS
IMPACT
IMPACT
IMPACT N
44
Example 3: Mail distribution
• Modular structure ?
- Constructs ?
• Human actors executing formal/informal procedures
- CE ?
• Visible at runtime (resources): Violation of SoC ?
45
Example 3: Mail distribution
F
C
Centralized
Execution of
BP & IS
Real World
Procedure: ‘our university
applies … rounding’
Centralized &
virtual e-mail office
Change:
Procedure v2
N
IMPACT
46
Real World
• Modular structure ?
- Constructs ?
• Manual: actors, departments, manual databases, manual
procedures, …
• (IT-based execution):
- CE ?
• Violations of SoC may occur
- Violations of SoC are close to discussions in management literature
on
» ‘decentralization vs centralization’
» ‘the need for matrix organizations on top of departments’
» ‘the need for business processes on top of departments’
» => EE and Organizational Sciences meet !
» Remark: Organizational Sciences have swinging
preferences over time for many of these topics…
• Implications
- Enterprises, even manual ones, have limited evolvability
47
UML OO Domain Models
UML OO Domain Models
49
OO Domain Models
• Modular structures
- See OO programming… YES !
• CE
- Data:
• Codd’s normalization… but is this sufficient ?
- Functions:
• Violation of DvT: use of atomic data types
• Violation of SoS: Use of sync pipelines
• Coupling
- Is high coupling the reason that domain models
are not in widespread use in practice ?
50
DEMO/EO
• Are DEMO/EO models modular structures ?
- A few indications, but we did not focus on DEMO/EO
specifically in this paper !
• Similarities between DEMO and NS
- Separation of State in NS => P- and C-facts !
- Workflows in NS => structured aggregations of actions
into transactions
- Expansion in NS => instantiating transaction pattern in
DEMO
• Do DEMO/EO-models contain CE ?
-
Possibly…
In production acts…
In implementation, but is this DEMO/EO ?
In runtime behavior, but is this DEMO/EO ?
• Nevertheless, we should find out… see conclusion !
52
DEMO transactions
•
The production act of a transaction seems to
be a module consisting of a number of
tasks, detailed in the action models.
•
However, for each production act, there are
4 coordination acts  transactions are
aimed at coordination-intensive problems,
like enterprises consisting of human actors.
•
Actually, such transactions define the
interfaces of the modules !
-
Reminds of negotiation at operational level,
but also project level (~IS acceptance
problems)
This is why DEMO/EO works so well: it is
human modularity, which is used to
control complexity, and…
53
DEMO transactions
• Reduce complexity by 7090 %
• By using the transaction
pattern, with the same
internal structure, for all
transactions
• = similar approach to NS
expansion !
54
Conclusion
CE exist at all these levels !
Strategy
RW
PPM/EA
DEMO/EO
PM
Use Cases
Domain Models
NS @ Enterprise=
Normalized
Transformation
Over the
F/C gaps
RE/Analysis
(Alberto Silva’s group)
Design
BPMN
NS@
Software
Implementation
Increasing
modular
structure
Maintenance
60
Conclusions
• Examples of CE’s are relatively straightforward but
- they are sufficient to illustrate the omnipresence of instabilities
in a domain that is sometimes considered to be about
"identification of objects in the real world”.
- at the software, heuristics have shown to be insufficient to
control the large number of highly complex CEs that are
responsible for the symptoms of Lehman’s law.
- Some examples of CE’s correspond to technical advances
• Eg. The shift from physical to e-mail
• => this CE is no marginal detail !
• Implications
- Initially, when the system is small, the CE’s would probably not
be problematic, but over time their effects would grow and
slowly but surely increase the rigidity of requirements models
and specifications (which are sometimes used as the technical
documentation of the information system, or a component in a
legal contract concerning the system).
61
Conclusions - Research Agenda
1. Identification of CE at each enterprise level at
compile-, deployment- and runtime, as well as
entropy-related issues
2. Mechanisms to control CE
1. Expansion/tooling (hypertext support in RE-tool?)
2. (semi-)manual mechanisms at E-level ?
3. Appropriate levels of control at each
enterprise level
1.
2.
The examples show that these CE exist, and many
employees will feel that they should be removed => NS
perspective on Enterprises is not ‘too technical’, but
at the same time: Enterprises remain human entities, and
it is extremely unlikely that they should be normalized to
the same extent as software !
62
Conclusions - Research Agenda
• Approach: domain-dependent artifacts, such as
in classical engineering !
- “loosely coupled artifacts need to be developed in
areas such as finance, accounting, transport,
human resources, or in subareas such as invoicing,
staffing, project management, mail distribution,
payments, etc.”
- Then: “When these artifacts are developed using a
modular structure which exhibits control of coupling
issues (such as a low number of CE), they can be
aggregated into higher-order structures such as
an invoice.”
- Ex: PhD Els Vanhoof: simple problem, no solution in
2013 !
63
Link to Business Meeting…
This paper illustrates how Antwerp and Lisbon were able
to collaborate, in the context of Alberto Silva’s sabbatical
! Let’s continue this, and do more, because…
“In this way, we support the call by Dietz et al. for the
area of Enterprise Engineering to be developed [33].
The amount and complexity of issues that need to be
solved to achieve the next generation of truly agile
enterprises both in the service and industrial sector,
both in the for-profit and not-for-profit sector, is such that
a scientific basis focusing on structural issues
(including coupling) will be required.”
Thank you for your attention !
64