User involvement in healthcare technology development and assessment: Structured literature review

Purpose – Medical device users are one of the principal stakeholders of medical device technologies. User involvement in medical device technology development and assessment is central to meet their needs. Design/methodology/approach – A structured review of literature, published from 1980 to 2005 in peer-reviewed journals, was carried out from social science perspective to investigate the practice of user involvement in the development and assessment of medical device technologies. This was followed by qualitative thematic analysis. Findings – It is found that users of medical devices include clinicians, patients, carers and others. Different kinds of medical devices are developed and assessed by user involvement. The user involvement occurs at different stages of the medical device technology lifecycle and the degree of user involvement is in the order of design stage > testing and trials stage > deployment stage > concept stage. Methods most commonly used for capturing users’ perspectives are usability tests, interviews and questionnaire surveys. Research limitations/implications – We did not review the relevant literature published in engineering, medical and nursing fields, which might have been useful. Practical implications – Consideration of the users’ characteristics and the context of medical device use is critical for developing and assessing medical device technologies from users’ perspectives. Originality/value – This study shows that users of medical device technologies are not homogeneous but heterogeneous, in several aspects, and their needs, skills and working environments vary. This is important consideration for incorporating users’ perspectives in medical device technologies. Paper type: Literature review

In search of requirements analyst characteristics that influence requirements elicitation effectiveness: a quasi-experiment

Context: Elicitation effectiveness depends on non-wellunderstood analyst?s skills and abilities. Identifying which analysts? characteristics have stronger influence on elicitation may help to improve requirements quality. Objective: Identify the analysts? characteristics that influence on the elicitation effectiveness. Method: We analyzed the impact of: the analyst?s experience in interviews, elicitation and requirements; their academic qualifications, the familiarity with problem domain and the time spent during the elicitation session in the effectiveness of the elicitation and subsequent consolidation of requirements, using a quasi-experiment. Results: The knowledge of the problem domain, the analysts? academic qualifications and the elicitation time do not appear to influence the effectiveness of the elicitation sessions. The analyst?s experience exerts a slight negative influence on the effectiveness of the elicitation session. The analyst?s experience and familiarity with problem domain adversely affect the consolidation process. Finally, the analyst?s academic qualifications have a strong positive impact(statistically significant) on the effectiveness of the consolidation process. Conclusions: Although the evidence is still scarce, it seems the analyst's confidence on his own experience may be harmful in some cases. Specific training in software requirements may yield much higher gains than non-specific analyst experience

Strategies to manage quality requirements in agile software development: a multiple case study

Agile methods can deliver software that fulfills customer needs rapidly and continuously. Quality requirements (QRs) are important in this regard; however, detailed studies on how companies applying agile methods to manage QRs are limited, as are studies on the rationale for choosing specific QR management practices and related challenges. The aim of this study was to address why practitioners manage QRs as they do and what challenges they face. We also analyzed how existing practices mitigate some of the found challenges. Lastly, we connect the contextual elements of the companies with their practices and challenges. We conducted 36 interviews with practitioners from four companies of varying sizes. Since each company operates in different domains, comparing QR management strategies and related challenges in different contexts was possible. We found that the companies apply proactive, reactive, and interactive strategies to manage QRs. Additionally, our study revealed 40 challenges in six categories that companies applying agile methods may face in QR management. We also identified nine contextual elements that affect QR management practice choices and which, importantly, can explain many related challenges. Based on these findings, we constructed a theoretical model about the connection between context, QR management practices, and challenges. Practitioners in similar contexts can learn from the practices identified in this study. Our preliminary theoretical model can help other practitioners identify what challenges they can expect to face in QR management in different developmental contexts as well as which practices to apply to mitigate these challenges.This work was supported by the European Union’s Horizon 2020 Research and Innovation Programme under Grant Agreement 732253.Peer ReviewedPostprint (published version

Effectiveness of Elicitation Techniques in Distributed Requirements Engineering

Software development teams are often geographically distributed from their customers and end users. This creates significant communication and coordination challenges that impact the effectiveness of requirements engineering. Travel costs, and the local availability of quality technical staff increase the demand for effective distributed software development teams. This research reports an empirical study of how groupware can be used to aid distributed requirements engineering for a software development project. Six groups of seven to nine members were formed and divided into separate remote groups of customers and engineers. The engineers conducted a requirements analysis and produced a software requirements specification (SRS) document through distributed interaction with the remote customers. We present results and conclusions from the research including: an analysis of factors that effected the quality of the Software Requirements Specification document written at the conclusion of the requirements process and the effectiveness of requirements elicitation techniques which were used in a distributed setting for requirements gathering

An introduction to STRIKE : STRuctured Interpretation of the Knowledge Environment

Knowledge forms a critical part of the income generation of the system and the complex environment in which actors participate in the creation of knowledge assets merits robust, eclectic consideration. STRIKE - STRuctured Interpretation of the Knowledge Environment affords an unobtrusive and systematic framework to observe, record, evaluate and articulate concrete and abstract elements of a setting, across internal and external dimensions. Inter-relationships between actor and environment are preserved. STRIKE is supported by underlying techniques to enrich data and enhance the authenticity of its representation. Adoption of photography and videography tools provides illustrative and interpretive benefits and facilitates researcher reflexivity. This structured approach to data analysis and evaluation mitigates criticisms of methodological rigour in observational research and affords standardisation potential, germane for application in a verification or longitudinal capacity. Advancing exploratory validation studies, the method is employed to evaluate the knowledge environments of two enterprises in the UK creative sector. These occupy a critical role in fostering entrepreneurial innovation alongside participant self-efficacy. Access Space in Sheffield and the Bristol Hackspace are committed to open software, open knowledge and open participation; sharing peer learning, creativity and socio-technical aims to address broadly similar community needs. Drawing on Wittgenstein’s Picture Theory of Meaning, the knowledge management perspective is abstracted from the STRIKE assessment. It is argued that the tiered analytical approach which considers a breadth of dimensions enhances representation and interpretation of the knowledge environment and presents a diagnostic and prescriptive capability to actualise change. The paper concludes by evaluating framework effectiveness, findings application and future direction

Configuring Crowdsourcing for Requirements Elicitation

Crowdsourcing is an emerging paradigm which utilises the power of the crowd in contributing information and solving problems. Crowdsourcing can support requirements elicitation, especially for systems used by a wide range of users and working in a dynamic context where requirements evolve regularly. For such systems, traditional elicitation methods are typically costly and limited in catering for the high diversity, scale and volatility of requirements. In this paper, we advocate the use of crowdsourcing for requirements elicitation and investigate ways to configure crowdsourcing to improve the quality of elicited requirements. To confirm and enhance our argument, we follow an empirical approach starting with two focus groups involving 14 participants, users and developers, followed by an online expert survey involving 34 participants from the Requirements Engineering community. We discuss our findings and present a set of challenges of applying crowdsourcing to aid requirements engineering with a focus on the elicitation stage

Online training courses on Expert Knowledge Elicitation (EKE)

This report summarises the training courses delivered under the contract OC/EFSA/AMU/2021/02 EKE: “Develop and conduct online training courses on Expert Knowledge Elicitation (EKE)”. The objective of the courses was to develop and conduct online training courses on applying the methodology described in the EFSA Guidance on Expert Knowledge Elicitation in Food and Feed Safety Risk Assessment” for EFSA staff and experts, as well as corresponding experts from EU member states. In addition to the three standard EKE methods (Sheffield, Delphi and Cooke), the training included a semi-formal method of EKE. All these methods may be used when EKE is performed within an existing EFSA working group to support uncertainty analysis as outlined in “The principles and methods behind EFSA\u27s Guidance on Uncertainty Analysis in Scientific Assessment”. In total, 12 courses were organised: two on “Steering an Expert Knowledge Elicitation”, two on “Conduct of the Sheffield protocol for an EKE”, one on “Conduct of the Cooke protocol for an EKE”, one on “Conduct of the Delphi protocol for an EKE”, two on “Conduct of a Semi-formal EKE”, two on “Reporting an Expert Knowledge Elicitation” and two on “Writing an Evidence Dossier for an Expert Knowledge Elicitation”. The courses had in total 149 participants and received very good feedback from the participants with a mean value of 4.2 of 5 possible, considering all numerical questions in the feedback questionnaire. Recommendations for future activities on training EKE methodologies are provided

DREQUS: an approach for the Discovery of REQuirements Using Scenarios

ABSTRACT: Requirements engineering is recognized as a complex cognitive problem-solving process that takes place in an unstructured and poorly-understood problem context. Requirements elicitation is the activity generally regarded as the most crucial step in the requirements engineering process. The term “elicitation” is preferred to “capture”, to avoid the suggestion that requirements are out there to be collected. Information gathered during requirements elicitation often has to be interpreted, analyzed, modeled, and validated before the requirements engineer can feel confident that a complete set of requirements of a system have been obtained. Requirements elicitation comprises the set of activities that enable discovering, understanding, and documenting the goals and motives for building a proposed software system. It also involves identifying the requirements that the resulting system must satisfy in to achieve these goals. The requirements to be elicited may range from modifications to well-understood problems and systems (i.e. software upgrades), to hazy understandings of new problems being automated, to relatively unconstrained requirements that are open to innovation (e.g. mass-market software). Requirements elicitation remains problematic; missing or mistaken requirements still delay projects and cause cost overruns. No firm definition has matured for requirements elicitation in comparison to other areas of requirements engineering. This research is aimed to improve the results of the requirements elicitation process directly impacting the quality of the software products derived from them

Topics in Software Engineering

Software engineering is a discipline which specifies, designs, develops, and maintains software applications. It applies practices and technologies from computer science. Software engineering is the backbone of software systems and forms the basis of operational design and development of software systems. Analysts use requirements elicitation techniques to ascertain the needs of customers and users, with the goal being a system that has a high chance of satisfying those needs. Success or failure of system development relies heavily on the quality of requirements gathering. Software modeling is an essential part of the software development process. Models are built and analyzed before the implementation of a system and are used to direct implementation.The Unified Modeling Language (UML) provides a standard way to visualize the design of a system. During the planning and design stages, software engineers must consider the risks involved in developing a system. Software must solve a problem and must respond to both functional and nonfunctional requirements. Software systems generally follow a pattern or an architectural style. We show the initial steps of developing a software system, define its specification and design topics, and demonstrate their creation by presenting a case study