Requirements engineering scenario based software requirement specification
0 likes468 views
The document discusses a workshop on requirements engineering, focusing on the successful methodologies used in the ehr4cr project aimed at promoting the reuse of electronic health records for clinical trials across Europe. It outlines the iterative processes of requirements gathering, analysis, specification, and validation, emphasizing the importance of stakeholder engagement and the use of scenarios for effective requirements management. The workshop also highlights the development and application of tools, platforms, and strategies necessary for enhancing clinical research through improved requirements engineering practices.
Requirements engineering scenario based software requirement specification
- 1. Requirements Engineering – Writing the Software Requirements Specification (SRS) Joint CRI Group Workshop UDUS, Duesseldorf, Germany 26.9.2017 Wolfgang Kuchinke
- 2. Introduction
- 3. Purpose of the workshop • The requirements enginering approach employed successfully in the EHR4CR process is shown in order to use it for new projects
- 4. Requirements engineering • Process of eliciting stakeholder needs and desires and developing them into an agreed-upon set of detailed requirements • Serves as basis for all subsequent development activities • Make the problem clear and complete, and to ensure that the developed solution is correct, reasonable, and effective W. Kuchinke (2017)
- 5. Begin with requirements acquisition • In general, a project begins with the requirements acquisition phase • Ends with the specification of requirements • Often projects begin with the analysis phase • Sometimes some kind of requirements specification exists, often in form of functional specifications • Requirements specification may be used to manage the consistency of the entire system W. Kuchinke (2017)
- 6. Aim • The Requirements Engineering process played a major part in the EHR4CR project • It was successfully conducted • It applied Requirements Scenarios and an iterative approach for Requirements Engineering and writing the Software Requirements Specification (SRS) • Prototyping was used • Therefore, it is very suitable to be used as a model to improve Requirements Engineering in other projects
- 7. Overview • Learning from the Requirements Engineering process in the the EU project EHR4CR • Ability to use the requirement gathering process for other EU projects • Topics – Requirements Engineering Process – Role of Requirements Scenarios in the process of requirement gathering – Introduction to software requirements specification (SRS) document W. Kuchinke (2017)
- 9. Project Objectives • Promotion of re-use of EHRs to accelerate regulated clinical trials, across Europe • EHR4CR project produced – Requirements specification for EHR systems to support clinical research and for integrating information across hospitals in different countries – EHR4CR Technical Platform (consisting of tools and services) – Pilots for validating the solutions – EHR4CR business model • Requirements were generated for the use of EHR for clinical trials W. Kuchinke (2017)
- 10. Electronic Health Records for Clinical Research • Providing adaptable, reusable and scalable solutions (tools and services) for reusing data from EHR systems for clinical research • The EHR offers significant opportunities for the advancement of medical research, the improvement of healthcare, and the enhancement of patient safety W. Kuchinke (2017)
- 11. The EHR4CR Scenarios • Protocol feasibility • Patient identification recruitment • EHR-EDC integration • Pharmaco-vigilance • Scenarios act – Across different therapeutic areas: oncology, inflammatory diseases, neuroscience, diabetes, cardiovascular diseases etc. – Across different EU countries under different legal frameworks
- 12. The Setting • Central role: Study Manager – Needs to monitor site recruitment performance • Role: Investigator – Needs to identify local patients that meet protocol inclusion / exclusion criteria – Patients can be recruited for clinical trial participation • This may require the research physician to reach out to local treating physicians for candidates / referrals
- 13. Electronic Health Records for Clinical Research • EHR4CR project set out to find ways to allow researchers running clinical trials to search medical records in hospitals across Europe • Discover potentially suitable patients for clinical trials • Assessment of the number of potential trial patients from the hospitals’ electronic records • Guarantee privacy protection of sensitive data – https://www.imi.europa.eu/projects-results/project- factsheets/ehr4cr – Final Report: https://www.imi.europa.eu/sites/default/files/uploads/documents/pr ojects/EHR4CR_summary_final_report.pdf
- 14. EHR4CR Technical Platform • Feasibility, exploration, design and execution of clinical studies • Long-term surveillance of patient populations • Trial eligibility and recruitment criteria must be expressed in ways that permit searching for suitable patients across different EHR systems • Access to multiple heterogeneous and distributed EHR systems • Integration with existing clinical trials infrastructures (e.g. EDC systems for data collection) • Improvement of data quality to enable routine clinical data to contribute to clinical trials W. Kuchinke (2017)
- 15. Services offered by the platform
- 17. The four Steps of the Requirements Process Model • Requirements Elicitation – the art to receive meaningful requirements • Requirements Analysis – iterative improvement of quality of requirements • Writing the Requirements Specification document (Software Requirement Specification) • Requirements Validationthis- this is also done iteratively with several workshops
- 18. Requirements Engineering Process Model Requirements Management Requirements Management •Requirements Specification Document •Requirements Specification Document •Reviews / Workshops •Stakeholder issues •Legal framework •Developer / IT engineer issues •Reviews / Workshops •Stakeholder issues •Legal framework •Developer / IT engineer issues •Conceptual modeling •Classification, prioritization •Conceptual modeling •Classification, prioritization •Identification of stakeholders & user •Understanding user and stakeholder needs •Surveys, Interviews, … •Identification of stakeholders & user •Understanding user and stakeholder needs •Surveys, Interviews, … Requirements Elicitation Requirements Elicitation Requirements Analysis Requirements Analysis Requirements Specification Requirements Specification Requirements Validation Requirements Validation
- 19. Not only requirements, but quality requirements • Aim is not only to gather requirements, but quality requirements • Quality requirement refer to a condition or a capability that must be present in a requirement • Represent what is needed to validate the successful completion of a project deliverable • It contains means for the validation of the acceptability of the requirements
- 20. Requirements engineering is a cyclic process • Requirements gathering • Analysis • Implementation • Software Testing • Evaluation of requirements • Improvement of software / creation of new requirements W. Kuchinke (2017)
- 22. Iterative process of requirements engineering • Develop a system through repeated cycles • Start with only a subset of software requirements, iterate until the full system is implemented • In each iteration, design modifications are made and new functional capabilities are added • Topics to be considered – Protocol Feasibility – Patient Recruitment – Trial Execution, Clinical Data Collection, Adverse Events Reporting W. Kuchinke (2017)
- 23. Tools for requirements gathering • Use Cases • Current situation and workflow • Context diagram • Stakeholder interviews • Concentration on the essence of the work / software • Use Case workshop – Scenarios, rules, analysis and discussion
- 24. A novel scenario based approach • Starting with a subset of the software requirements • Iteration by addition of requirements until the full platform is specified • Each iteration step – Design modifications are made – New functional capabilities are added – The domain scenario is used to estimate probable effects (situation analysis and long-range planning) • The domain scenario describes the entire domain – It is broken down into high-level ‘Usage Scenarios’ • Usage Scenarios describe critical business interactions and their anticipated operations – They serve as context for the use cases and the generation of requirements – They make sure requirements are complete W. Kuchinke (2017)
- 26. Requirements generation by using scenarios
- 27. Findings of the stakeholder interviews • Requirements elaborated based on interviews with pharma & academic domain experts • Challenges were identified for the generation of queries and the handling of temporal relations in EHR4CR • Differences were identified between pharma and academia W. Kuchinke (2017)
- 28. Example result: Requirements based on Workshops
- 29. Two types of requirements • Functional requirements – Level of detail and granularity – Exceptions and alternatives – Avoiding ambiguity – Technological requirements – Activity diagrams • Nonfunctional requirements – Look and feel – Usability – Performance – Legal and security – Maintainability
- 31. Development of Use Cases Problem environment Business Use Case Product Use Case Process 1 Process 2 Process 4 Process 3 Described as Use Case Actor Use case
- 32. Writing the requirements • Requirement Specifiction Dokument – SRS – Volere template – Open issues, risks, costs, training • Quality control of requirements – Consistent terminology – Completeness – Meaningfulness – Traceability of relevance to purpose – Viable within constraints W. Kuchinke (2017)
- 33. Writing good requirements • Requirements should be unambiguous • Requirements should be short • Requirements must be feasible • Requirements should be prioritized • Requirements should be testable • Requirements should be consistent • Requirements use „shall“ • See: Appendix C. How to Write a Good Requirement- https://www.nasa.gov/seh/appendix-c-how-to-write-a- good-requirement W. Kuchinke (2017)
- 34. Prototyping • Use simulations – Help to find requirements – Validation of requirements • Prototyping of requirements for – User Interface – Design and build of software – Testing UI in real user environment W. Kuchinke (2017)
- 35. Resources • https://www.volere.org/templates/volere-requiremen ts-specification-template/ • Book: Mastering the Requirements Process by Suzanne Robertson and James Robertson • Contents – Project Drivers, Constraints, Functional Requirements, Non-functional Requirements, Performance Requirements, Operational and Environmental Requirements, Maintainability and Support Requirements, . Security Requirements, Legal Requirements, Project Issues, Open Issues, Risks, Costs, User Documentation and Training
- 36. The final step is the development of the complete SRS document
- 37. Purpose of the SRS in EHR project • Description of the expected functionalities of the EHR4CR platform • Focus is on the envisaged functionality provided by EHR4CR to identify individual subjects that match a set of pre-defined criteria • Support of further follow-up and possible enrolment of the subject in clinical studies W. Kuchinke (2017)
- 38. Development of the SRS with involvement of Scenarios W. Kuchinke (2017) 1.Begin with Domain Scenarios 2.Development of Usage Scenarios 3. Software Requirements Specification Document – Is the basis for building the software – Begins with the Capabilities Description Document, a high-level description of the envisaged system that is extensively discussed by all stakeholders – Contains also mockups, workflows and use cases
- 39. SRS of EHR4CR - Overview of Content • Tools and methods used for the specification of the EHR4CR platform • Actors, brief description and associated responsibilities of actors / roles involved • Use cases specify the envisaged usage of the EHR4CR system in terms of a conceptual model • Functional requirements, which documents and specifies required functionalities of the envisaged system • Non-functional requirements • Data Requirements • Appendix: GUI mock-up W. Kuchinke (2017)
- 40. Change management for requirements • Several round of change management were employed • Extensive change management during writing the SRS • Extensive discussions and at least two iterations • This possibility for correction and improvement ensured that the requirements had a high quality
- 41. Change management during writing the SRS Problems, Defects, Innovation, Tuning identified Change Request • Report to advisory board for Requirements Management Analysis & Prioritisation • Analysis and prioritisation of change requests • Estimation of efforts Planning • Planning for improvement • Change advisory board judgement • Next steps Release, Version • Documentation of Changes • Refusal causes delay and new iteration step • Acceptance means new version of SRS
- 42. Validation of Requirements • Validation workshop is well suited for discussion the requirements • 2 review iterations were conducted • Writing a document that contains all remarks, questions and comments connected to the requirements provided by reviewers and the response from requirements engineering team • This document makes it easier to generate a high quality Requirements Specification Documents (SRS)
- 43. Enhancement to Requirements Engineering • Several enhancements were introduced introduced into the requirements engineering process – Use of GUI Mock-ups to envisage workflows and main use cases – Prototyping of most important requirements – Requirements Workshops with many different Working Groups – Inclusion of working group for legal/ethical issues requirements) – Inclusion of many Domain Experts (Patient Identification & Recruitment) from hospitals and pharma industry – Involvement with the Validation of Requirements W. Kuchinke (2017)
- 44. New projects where requirements engineering was applied
- 45. New projects to apply the requirement engineering process • CORBEL project – Stakeholder Needs and Requirements Document – Sharing and re-use of individual participant data from clinical trials • BioMedBridges project – Legal requirements specification – Building data bridges between biological and medical infrastructures in Europe – Legal and privacy requirements during data sharing to guarantee legal interoperability • p-medicine project – Generation of legal and ethical requirement clusters W. Kuchinke (2017)
- 46. Example: Ethical requirement clusters For the p-medicine project different legal and ethical requirements were combined to requirement clusters
- 47. Example: Requirements engineering for LAT For the BioMedBridges project requiremens engineering was used to generate legal requirements for data sharing W. Kuchinke (2017)
- 48. Contact Wolfgang Kuchinke UDUS, Duesseldorf, Germany This presentation contains additional explanatory material for Q&A and workshop wolfgang.kuchinke@uni-duesseldorf.de wokuchinke@outlook.de Presentation motive from freepik.com