Presentation at the 14th International Conference on Evaluation of Novel Approaches to Software Engineering - ENASE 2019

1. Integrating Users Logic into
Requirements Engineering for
Connected Healthcare co-Design
Authors: Sofia Ouhbi, Maria Karampela and Minna Isomursu

2. Outline
§ Requirements Engineering
§ S-D logic
§ Integrating the users logic into Requirements Engineering
§ Conclusions and future works

3. Requirements Engineering
3

4. Requirements ISO/IEC/IEEE 29148:2011
4
• statement which translates or expresses a need and its associated constraints and
conditions
Requirement:
• interdisciplinary function that mediates between the domains of the acquirer and
supplier to establish and maintain the requirements to be met by the system,
software or service of interest
Requirements engineering:
• discovering, eliciting, developing, analyzing, determining verification methods,
validating, communicating, documenting, and managing requirements
Requirements engineering is concerned with:

5. Software requirements ISO/IEC 25030
5
Systemrequirements
Softwarerequirements
Softwareproduct
requirements
Other system
requirements
Software
development
requirements
Include for example requirements for computer hardware, data,
mechanical parts, and human business processes
Development organisation requirements
Development process requirements
Inherent
property
requirements
Functional requirements
Quality in use requirements
External quality requirements
Assigned
property
requirements
Managerial requirements including for example
requirements for price, delivery, date, product future, and
product supplier
Internal quality requirements
Software quality
requirements

6. Process for requirements development
6
Requirements Elicitation is concerned with the origins of software
requirements and how the requirements engineer can collect
them.
It is fundamentally a human activity where the stakeholders are
identified and relationships established between the
development team and the customer.
Requirements Analysis is undertaken to detect and
resolve conflicts between requirements; discover the
bounds of the software and how it must interact with its
environment; and to classify requirements.
Requirements Specification results in the specification of the users
and system requirements which can establish the system
requirements specification (SyRS) document and the software
requirements specification (SRS) document.
Requirements
elicitation
Requirements
analysis
Requirements
specification
Requirements
validation
Requirements Validation is the last phase of the
requirements development process and it is crucial as
mirrors the elicitation of requirements phase. This phase
validates whether the requirements of the customers
have been met or not, so that it gives a reply to the
question “did we create the right product?”

7. Problems related to weak requirements
7
Weak
requirements
engineering
• Unstable product
• Unclear responsibilities
• Gaps between
customer expectations
and project content
• …
Errors

8. Problems related to weak requirements
8
Chaos Report
!
Success/Failure Profiles!
The most important aspect of the research is discovering why projects fail. To do
this, The Standish Group surveyed IT executive managers for their opinions about
why projects succeed. The three major reasons that a project will succeed are user
involvement, executive management support, and a clear statement of
requirements. There are other success criteria, but with these three elements in
place, the chances of success are much greater. Without them, chance of failure
increases dramatically.!
!
8© 2014 Project Smart. All rights reserved.
Project Success Factors % of Responses
1. User Involvement 15.9%
2. Executive Management Support 13.9%
3. Clear Statement of Requirements 13.0%
4. Proper Planning 9.6%
5. Realistic Expectations 8.2%
6. Smaller Project Milestones 7.7%
7. Competent Staff 7.2%
8. Ownership 5.3%
9. Clear Vision & Objectives 2.9%
10. Hard-Working, Focused Staff 2.4%
Other 13.9%
Chaos Report
!
The survey participants were also asked about the factors that cause projects to be
challenged.!
Opinions about why projects are impaired and ultimately cancelled ranked
incomplete requirements and lack of user involvement at the top of the list.
9© 2014 Project Smart. All rights reserved.
Project Impaired Factors % of Responses
1. Incomplete Requirements 13.1%
2. Lack of User Involvement 12.4%
3. Lack of Resources 10.6%
4. Unrealistic Expectations 9.9%
5. Lack of Executive Support 9.3%
6. Changing Requirements & Specifications 8.7%
7. Lack of Planning 8.1%
8. Didn't Need It Any Longer 7.5%
9. Lack of IT Management 6.2%
10. Technology Illiteracy 4.3%
Other 9.9%
Chaos Report
!
The survey participants were also asked about the factors that cause projects to be
challenged.!
Opinions about why projects are impaired and ultimately cancelled ranked
incomplete requirements and lack of user involvement at the top of the list.
Project Challenged Factors % of Responses
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%

9. Design challenges due to poor requirements Examples
9
A typical example of software failure due to exclusion of users to the requirements development process
HealthCare.gov launched on October 2013, failed to serve users needs due to various issues.
• Inaccurate forecasting of user population which resulted to accessibility issues
• Various system and software design failures which were related to poor user evaluation
• Failure to test scalability and include end-users to the design process
“I’m going to try and download every movie ever made, and you’re going to try to sign up for
Obamacare, and we’ll see which happens first”
Jon Stewart challenging Kathleen Sebelius (former Secretary of Health and Human Services) to a race.

10. Design challenges due to poor requirements Examples
10
The UK’s National Programme for IT (NPfIT) web
service was an effort to offer a centralized electronic
health record (EHR) that would be accessible by
patients and also would connect general
practitioners and hospitals’ records.
After its implementation the software was scrapped
due to several failures such as poor functionality
connected to exclusion of end-users and
stakeholders in the design process.

11. Challenges facing connected health
The enthusiasm by health leaders and policy makers for new technologies is not always reflected by
adoption and utilisation in practice..
It is argued that a focus on technology over the formulation of a well-defined value proposition have
resulted in many e-health project failures.
Healthcare organisations must re-evaluate traditional boundaries due to the complexity of
connected health technologies necessary for collaboration and co-creation.
Integrating the users logic into Requirements Engineering offers an alternative stakeholder-centric
construct.
11

12. S-D Logic
Service Dominant Logic
12

13. S-D Logic?
Service-Dominant (S-D) Logic is a mindset for a unified understanding of the purpose and nature of
organizations, markets and society.
The foundational proposition of S-D logic is that organizations, markets, and society are
fundamentally concerned with exchange of service—the applications of competences (knowledge
and skills) for the benefit of a party.
That is, service is exchanged for service; all firms are service firms; all markets are centered on the
exchange of service, and all economies and societies are service based.
13
Source: sdlogic.net

14. S-D Logic
Instead of service marketing “breaking free” from goods marketing, as has been the pursuit of the
services marketing sub-discipline for the last several decades, all of marketing needs to break free
from the goods and manufacturing-based model—that is, goods-dominant (G-D) logic.
S-D logic embraces concepts of the value-in-use and co-creation of value rather than the value-in-
exchange and embedded-value concepts of G-D logic.
Instead of firms being informed to market to customers, they are instructed to market with customers,
as well as other value-creation partners in the firm’s value network.
14
Source: sdlogic.net

15. Goods-Dominant Logic Model
15
Supplier Producer ConsumerSupply chain
Product/
Value
Delivery
Goods/
Money
Value
Destruction
Value
C
reation

16. G-D Logic
Products Tangible
Services Intangible
S-D Logic
Direct
Indirect
Goods
Money
G-D Logic vs S-D Logic
16

17. Axioms, Foundational Premises and Concepts of S-D Logic
17
Axiom1FP1Service is the fundamental basis of exchange.
FP2Indirect exchange masks the fundamental basis of exchange.
FP3Goods are a distribution mechanism for service provision.
FP4Operant resources are the fundamental source of strategic benefit.
FP5All economies are service economies.
Axiom2FP6Value is co-created by multiple actors, always including the beneficiary.
FP7Actors cannot deliver value but can participate in the creation and offering of value propositions.
FP8A service-centered view is inherently beneficiary oriented and relational.
Axiom3FP9All social and economic actors are resource integrators.
Axiom4FP10Value is always uniquely and phenomenologically determined by the beneficiary.
Axiom5FP11Value co-creation is coordinated through actor-generated institutions and institutional arrangements.
Source: Vargo and Lusch (2016), "Institutions and axioms: an extension and update of service-dominant logic" Journal of the Academy of Marketing Science, 1-19.

18. The Core Narrative & Processes of S-D Logic
18
Generic actors
Involved in
Resource Integration
and
Service Exchange
Enabled &
Constrained by
Endogenously
generated
Institutions & Institutional
Arrangements
Establishing
nested &
overlapping
Service ecosystems
Value
co-creation

19. S-D logic in healthcare
A G-D logic framing of the relationship between the provider and the patient views the provider as
experienced, knowledgeable, innovative, creative, and the source or creator of value. The patient is
viewed as inexperienced, unknowledgeable, passive or dull, and someone who consumes and uses
up or destroys value. This represents the logic of separation between producer and consumer or in
health care between health care providers and patients.
S-D logic is one of togetherness. Both the health provider and the consumer (or client or customer –
rather than patient) are sensing and experiencing, creating, integrating resources, and learning.
19

20. Integrating the users logic into RE
20

21. Integrating the users logic into RE
21
Requirements
elicitation
Requirements
analysis
Requirements
specification
Requirements
validation
Value
co-creation

22. Integrating the users logic into RE
Transforming knowledge, business and users’ needs into software components is a challenge by
itself. Our proposed framework based on S-D logic can contribute on that in different ways.
Considering software in the lens of service means that the focus of the requirements development
process should be shifted to the design of exchange of resources, so to the design of knowledge
and skills (Axiom1, FP1).
The idea of value-in-use is a notion that requirements development process can benefit from.
According to this notion, value is created by the beneficiaries of a service while using the services.
Moreover, the value is co-created by multiple actors including always the end-users (Axiom2, FP6).
Based on that, a suggestion would be to involve beneficiaries, patients in this case, along the
requirements development process. Their knowledge in each step of the requirements development
process could lead to the creation of more agile and effective solutions that will be aligned with
their needs.
22

23. Integrating the users logic into RE
The idea of a common objective for “collective wellbeing” amplifies the argument that stakeholders
involvement in the requirements development process can have positive impact (Axiom 3, FP9). The
contribution of this axiom is the notion that service ecosystems are environments that connect actors
under a common goal.
In case of healthcare services it is essential to involve patients into the design process as their needs
are often complex and unique, requiring thus solutions that are sensitive on that (Axiom4, FP10) as
value is always uniquely determined by the beneficiary.
More attention should be given to the commonalities of the stakeholders of a service than to the
differences (Axiom5, FP11).
23

24. Integrating the users logic into RE
• Software engineers could gain a better understanding of the complex network of actors focusing on different
perspectives within the same network. Mapping the actions and stakeholders could contribute to better
understanding of service ecology leading to the development of more agile solutions.
• Although the S-D logic framework could contribute towards better understanding of service ecology and
network of users, the education of the future software engineers can also facilitate them to better understand
and reflect upon users’ needs.
• Software engineers hold an essential role and an ethical responsibility to serve society by contributing towards
the creation of welfare services.
24

25. Future work
Our future work will focus on the refinement of the proposed
approach and the development of a model to support
software engineers to improve the requirements
development process for connected health systems.
We intend also to conduct empirical evaluation to validate
our proposed approach.
Our contribution presents a preliminary
discussion of S-D logic integration into the
requirements development process.
We discussed how the five core axioms of
the S-D logic, the service ecology and
reformation on education of engineers could
contribute on the re- design of the
requirements development process.
Conclusions

26. Thank you for your attention!
Questions?