Systematic research of Combinatorial Effects at Requirements Engineering Level
description
Transcript of Systematic research of Combinatorial Effects at Requirements Engineering Level
![Page 1: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/1.jpg)
Systematic research of Combinatorial Effects at Requirements Engineering Level
Jan VerelstAlberto Rodrigues SilvaHerwig MannaertDavid Almeida FerreiraPhilip Huysmans
![Page 2: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/2.jpg)
2
Overview• Introduction• Normalized Systems Theory• Identifying Combinatorial Effects
- BPMN- UML Use Cases- “Real World”- UML Domain Models- DEMO/EO
• Conclusions• Research agenda
![Page 3: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/3.jpg)
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.”
![Page 4: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/4.jpg)
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
![Page 5: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/5.jpg)
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
![Page 6: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/6.jpg)
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
![Page 7: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/7.jpg)
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…
![Page 8: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/8.jpg)
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
![Page 9: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/9.jpg)
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 !
![Page 10: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/10.jpg)
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
![Page 11: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/11.jpg)
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
![Page 12: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/12.jpg)
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
![Page 13: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/13.jpg)
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 !
![Page 14: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/14.jpg)
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
![Page 15: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/15.jpg)
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
![Page 16: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/16.jpg)
27
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
C
F
C
F
![Page 17: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/17.jpg)
BPMN models
![Page 18: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/18.jpg)
29
BPMN-createExpenseReimbursement
![Page 19: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/19.jpg)
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
![Page 20: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/20.jpg)
31
BPMN-with separated Task
BPMN Task
F
C
createExpenseReimbursement createBonusPayment N
checkAccountExistence
IMPACT
Real World
createBonusPayment
Change:
checkAccountExistence v2
Real World
createExpenseReimbursement
checkAccountExistence is shared
N
Remark:this is NOT an
NS element !
![Page 21: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/21.jpg)
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 !
![Page 22: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/22.jpg)
UML Use Cases
![Page 23: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/23.jpg)
34
UML Use CasesUse Case createExpenseReimbursement3. checkAccountExistence
4. createAccount…7. reimburse
Use CasecreateBonusPayment3. checkAccountExistence
4. createAccount5. executePayment
![Page 24: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/24.jpg)
35
UML Use Cases
Real World
Interviews (oral)
Interview transcripts
Use Cases
F
C
Change:
checkAccountExistence v2
IMPACT IMPACT
createExpenseReimbursement createBonusPayment N
IMPACT N
![Page 25: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/25.jpg)
36
UML Use Cases-with hypertext construct
Real World
Interviews (oral)
Interview transcripts
Use Cases
F
C
Change:
checkAccountExistence v2
createExpenseReimbursement createBonusPayment N
checkAccountExistence
IMPACT
Remark:this is NOT an
NS element !
![Page 26: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/26.jpg)
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)
![Page 27: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/27.jpg)
Real World
![Page 28: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/28.jpg)
39
Example 1: createExpenseReimbursement
Real World
Interviews (oral)
Interview transcripts
Manually
Executed
BP & IS (=paper)
F
C
Change:
checkAccountExistence v2:
“Use NL bank only from now !”
IMPACT IMPACT
Actor 1:
createExpenseReimbursement
Actor 2:
createBonusPayment
N
IMPACT N
![Page 29: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/29.jpg)
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 ?
![Page 30: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/30.jpg)
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
![Page 31: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/31.jpg)
42
Example 2: Exam Marks• Modular structure ?
- Constructs ?• Human actors executing formal/informal procedures
- CE ?• Visible at runtime (resources): Violation of SoC ?
![Page 32: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/32.jpg)
43
Example 2: Exam Marks – Compile Time Model
Real World
Procedure: ‘our university applies
… rounding’
Decentralized
Execution of
BP & IS
F
C
Change:
Procedure v2
INVISIBLE
IMPACT !!!
Procedure
Executed
by all Professors
N
![Page 33: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/33.jpg)
44
Example 2: Exam Marks
Real World
Procedure: ‘our university applies
… rounding’
Centralized
Execution of
BP & IS
F
C
Change:
Procedure v2
IMPACT
Student
Office
![Page 34: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/34.jpg)
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
![Page 35: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/35.jpg)
46
Example 3: Mail distribution• Modular structure ?
- Constructs ?• Human actors executing formal/informal procedures
- CE ?• Visible at runtime (resources): Violation of SoC ?
![Page 36: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/36.jpg)
47
Example 3: Mail distribution
Real World
Procedure: ‘our university applies
… rounding’
Centralized
Execution of
BP & IS
F
C
Change:
Procedure v2
IMPACT
Centralized &
virtual e-mail office
N
![Page 37: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/37.jpg)
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
![Page 38: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/38.jpg)
UML OO Domain Models
![Page 39: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/39.jpg)
50
UML OO Domain Models
![Page 40: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/40.jpg)
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 ?
![Page 41: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/41.jpg)
DEMO/EO
![Page 42: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/42.jpg)
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 !
![Page 43: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/43.jpg)
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…
![Page 44: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/44.jpg)
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 !
![Page 45: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/45.jpg)
Conclusion
![Page 46: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/46.jpg)
61
CE exist at all these levels !
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
C
F
C
F
![Page 47: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/47.jpg)
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).
![Page 48: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/48.jpg)
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 !
![Page 49: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/49.jpg)
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 !
![Page 50: Systematic research of Combinatorial Effects at Requirements Engineering Level](https://reader036.fdocuments.us/reader036/viewer/2022062521/56816975550346895de1595f/html5/thumbnails/50.jpg)
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 !