Requirements Engineering – Writing the Software Requirements Specification (SRS). A CRI Group Workshop. The requirements engineering approach employed successfully in the EHR4CR process is shown and discussed in order to extract lessons learned and to use it for new projects. Requirements engineering is the process of eliciting stakeholder needs and desires and develope them into an agreed set of detailed requirements. It serves as basis for all subsequent software development activities. In general, a project begins with the requirement acquisition phase and ends with the specification of requirements in form of the Software Requirement Specification (SRS). Requirements specification may even be used to manage the consistency of the entire system. Learning from the Requirements Engineering process in the the EU project EHR4CR. Especially the topics of Requirements Scenarios in the process of requirement gathering and the iterative writing and validation of software requirements specification (SRS) document can be applied to new projects. The Requirements Process consists of 4 steps: Requirements Elicitation – the art to receive meaningful requirements. Requirements Analysis – iterative improvement of quality of requirements. Writing the Requirements Specification document (Software Requirement Specification) and Requirements Validation - this is also done iteratively with several workshops. Novel is the introduction of an iterative process for requirements engineering. Start with only a subset of software requirements, iterate the collection and validation until the full system is implemented. In each iteration, design modifications are made and new functional capabilities are added. Following tools for requirements gathering were used: Use Cases, Descriptions of current situation and workflow, Context diagram, Stakeholder interviews, Scenarios and Use Case workshops. A novel scenario based approach for requirements engineering is being introduced: The domain scenario is used to estimate probable effects (situation analysis and long-range planning). The domain scenario 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. Development of the SRS with involvement of scenarios: 1. Begin with Domain Scenarios; 2. Development of Usage Scenarios; 3. Software Requirements Specification document. Several round of change management were employed during writing the SRS. This possibility for correction and improvement ensured that the requirements are of high quality and applicability.

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)

8. EHR4CR project

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

16. Overview Requirements
Engineering Process

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)

21. The requirements cycle

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

30. Functional Overview

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