Systematic research of Combinatorial Effects at Requirements Engineering Level

Systematic research of Combinatorial Effects at Requirements Engineering Level

Jan VerelstAlberto Rodrigues SilvaHerwig MannaertDavid Almeida FerreiraPhilip Huysmans

2

Overview• Introduction• Normalized Systems Theory• Identifying Combinatorial Effects

- BPMN- UML Use Cases- “Real World”- UML Domain Models- DEMO/EO

• Conclusions• Research agenda

3

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, process- based 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.”

4

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

5

Business and System Level• Business level

- Constructs• Terminology, goals, stakeholders, business processes, business use cases

- Languages/Models• Goal-oriented languages (i*, KAOS), UML, BPMN, RUP Business Modeling, DEMO/EO, Archimate

• System level- Context models

• Constructs- System, subsystem, componenents, nodes, external actors

• Languages- SysML Block Diagrams, UML Deployment Diagrams, Data Flow Diagrams

- Domain Models• Constructs

- Entities, classes, …• Languages

- UML Class Diagrams, Entity Relationship Diagrams- Functional requirements models

• Constructs- Actors, functional requirements, use cases, scenario’s, user stories

• Languages- Natural language enriched with metadata (priority, risk levels…), UML Use Case diagrams, SysML Requirements Diagrams

- Quality attribute models• Constructs

- Qualities, metrics, utility values, • Languages/Models

- lists of quality attributes, quality-attributes scenario’s

6

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-of-

date- RE requires considerable resources => inefficient

7

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…

8

NS @ software level

Struct Invoice

- Nr

- Date

- …

Struct Customer

- Name

- Address

- VATnr

- …Func computeInvoice Func inviteCustomer Func sendInvoice

Struct

Func

IMPACT

IMPACT IMPACT N

N

IMPACT

9

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.”• DVT: How do you combine a data and action module ?

- “Data entities that are received as input or produced as output by action entities, need to exhibit version transparency.”

• 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 !

10

NS SummaryAssumption:

Modular Structures:

Complexity ↑

X

Change ↑

Current Practice

1. Modularity

- Combinatorial Eff.

- White-box reuse

- Lehman

2. Standardization

- No expansion

NS-Determinism

1. Modularity

- No Combinatorial Eff.

- Black box reuse

- Lehman controlled

2. Standardization

- ExpansionFine-grained/

No Combinatorial Eff.

Expansion

Black-box reuse/

Lehman controlled

Lehman

11

NS as a simple transformation over F/C gap

Data

Tasks

Customer

-Name

-Address

-VATnr

…

Invoice

-Nr

-Date

-…

Struct Invoice

- Nr

- Date

- …

Struct Customer

- Name

- Address

- VATnr

- …

computeInvoice inviteCustomer sendInvoice

Func computeInvoice Func inviteCustomer Func sendInvoice

Struct

Func

F

C

Change:

addAttribute

IMPACT

IMPACT

N

IMPACT NIMPACT

14

The concern trapezoid

Business

ICT

Examples of concerns:

“Want innovative invoicing”

High-level business

- Strategy (innovation vs cost)

- Internationalisation

High-level ICT

- Stick with current package

- Commodity ICT

Human

- Stakeholder issues (political…)

- Communication, negotiation

Concerns are additive (?)

#concerns ↑↑ Examples of concerns:

Low level ICT:

- Performance of an algorithm or call to package

- Interface stability

- Internationalisation libraries present

- Technical security details

- …

F

C

15

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 !

16

NS as a complex transformation over F/C gap

Invoice

Element IMPACT

IMPACT

IMPACT

Customer

Element

invite

Customer

Element

compute

Invoice

Element

send

Invoice

Element

F

C

Customer

-Name

-Address

-VATnr

…

Invoice

-Nr

-Date

-…

computeInvoice inviteCustomer sendInvoice

Data

Tasks

Change:

addAttribute

Action

Elements

Data

Elements

26

Enterprise = n F/C gaps

Strategy

PPM/EA

PM

RE/Analysis

(Alberto Silva’s group)Design

Implementation

Maintenance

NS @ Enterprise=

Normalized

Transformation

Over the

F/C gaps

RW

DEMO/EO

Use Cases

BPMN

Domain Models

Increasing

modular

structure

NS@

Software

F

C

F

C

F

C

F

C

F

C

27

Enterprise = n F/C gaps

Strategy

PPM/EA

PM

RE/Analysis


Implementation

Maintenance

NS @ Enterprise=

Normalized

Transformation

Over the

F/C gaps

RW

DEMO/EO

Use Cases

BPMN

Domain Models

Increasing

modular

structure

NS@

Software

F

C

C

F

C

F

BPMN models

29

BPMN-createExpenseReimbursement

30

BPMN

Real World

createBonusPayment

BPMN Task

F

C

Change:

checkAccountExistence v2

IMPACT

N

IMPACT N

createExpenseReimbursement createBonusPayment

IMPACT

Real World

createExpenseReimbursement

checkAccountExistence is shared

N

31

BPMN-with separated Task

BPMN Task

F

C

createExpenseReimbursement createBonusPayment N

checkAccountExistence

IMPACT

Real World

createBonusPayment

Change:


Real World


checkAccountExistence is shared

N

Remark:this is NOT an

NS element !

32

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 !

UML Use Cases

34

UML Use CasesUse Case createExpenseReimbursement3. checkAccountExistence

4. createAccount…7. reimburse

Use CasecreateBonusPayment3. checkAccountExistence

4. createAccount5. executePayment

35

UML Use Cases

Real World

Interviews (oral)

Interview transcripts

Use Cases

F

C

Change:


IMPACT IMPACT


IMPACT N

36

UML Use Cases-with hypertext construct

Real World

Interviews (oral)


Use Cases

F

C

Change:



checkAccountExistence

IMPACT

Remark:this is NOT an

NS element !

37

Use Cases• Modular structure ?

- Constructs ?• YES

- 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, …

• NO- 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)

Real World

39

Example 1: createExpenseReimbursement

Real World

Interviews (oral)


Manually

Executed

BP & IS (=paper)

F

C

Change:

checkAccountExistence v2:

“Use NL bank only from now !”

IMPACT IMPACT

Actor 1:


Actor 2:

createBonusPayment

N

IMPACT N

40

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 ?

41

Example 2: Exam Marks

Real World

Procedure: ‘our university applies

… rounding’

Decentralized

Execution of

BP & IS

F

C

Change:

Procedure v2

IMPACT IMPACT

Professor 1 Professor 2N

IMPACT N

42

Example 2: Exam Marks• Modular structure ?



43

Example 2: Exam Marks – Compile Time Model

Real World


… rounding’

Decentralized

Execution of

BP & IS

F

C

Change:

Procedure v2

INVISIBLE

IMPACT !!!

Procedure

Executed

by all Professors

N

44

Example 2: Exam Marks

Real World


… rounding’

Centralized

Execution of

BP & IS

F

C

Change:

Procedure v2

IMPACT

Student

Office

45

Example 3: Mail distribution

Real World

Procedure: ‘our university allows

physical mail’

Decentralized

Execution of

BP & IS

F

C

Change:

Procedure v2

IMPACT IMPACT

Secretary 1 Secretary 2N

IMPACT N

46

Example 3: Mail distribution• Modular structure ?



47

Example 3: Mail distribution

Real World


… rounding’

Centralized

Execution of

BP & IS

F

C

Change:

Procedure v2

IMPACT

Centralized &

virtual e-mail office

N

48

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

UML OO Domain Models

50

UML OO Domain Models

51

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 ?

DEMO/EO

53

• 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 !

54

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…

55

DEMO transactions• Reduce complexity by 70-90 %• By using the transaction pattern, with the same internal

structure, for all transactions• = similar approach to NS expansion !

Conclusion

61

CE exist at all these levels !

Strategy

PPM/EA

PM

RE/Analysis


Implementation

Maintenance

NS @ Enterprise=

Normalized

Transformation

Over the

F/C gaps

RW

DEMO/EO

Use Cases

BPMN

Domain Models

Increasing

modular

structure

NS@

Software

F

C

C

F

C

F

62

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).

63

Conclusions - Research Agenda1. Identification of CE at each enterprise level at

compile-, deployment- and runtime, as well as entropy-related issues

2. Mechanisms to control CE1. Expansion/tooling (hypertext support in RE-tool?)2. (semi-)manual mechanisms at E-level ?

3. Appropriate levels of control at each enterprise level1. 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

2. at the same time: Enterprises remain human entities, and it is extremely unlikely that they should be normalized to the same extent as software !

64

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 !

65

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 !

Documents

Systematic research of Combinatorial Effects at Requirements Engineering Level