Integrating the users logic into Requirements Engineering
1 like94 views
The document discusses the integration of user logic into requirements engineering in connected healthcare, emphasizing the importance of user involvement to mitigate project failures. It highlights the challenges faced in healthcare IT projects due to insufficient user input and presents service-dominant logic (s-d logic) as a framework for enhancing stakeholder collaboration. The authors propose a shift towards incorporating the perspectives of end-users in the requirements development process to create more agile and effective healthcare solutions.
Integrating the users logic into Requirements Engineering
- 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
- 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 ProïŹles! 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 & SpeciïŹcations 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 & SpeciïŹcations 12.3% 3. Changing Requirements & SpeciïŹcations 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?