gms | German Medical Science

Introduction: The EHR4CR project has the aim to provide adaptable, reusable and scalable solutions (tools and services) for reusing data from Electronic Health Record systems for Clinical Research. Though, research is always a collaborative endeavor, establishing specifications between the different stakeholders and partners is always challenging.

Methodology: Requirements engineering is the process of determining what is to be produced in a software system. If one gets down to develop a software system, the requirements engineering process play a central role with the goal to determine the needs and the intended behaviour of a system. This process is often regarded as one of the most important parts of building a software system. In general, four steps in software requirements engineering are elicitation, analysis, specification and validation. Although defined as separate tasks, these processes cannot be strictly separated, performed sequentially or centrally. Requirements elicitation involves three main categories of stakeholders: the developers, the users and the customers, and can involve in addition other experts such as lawyers, standards organizations, patient organization, etc [1]. In this way, a successful requirements elicitation process includes effective ways to encourage all partners [2]. The requirements engineering process is a sub-process as well a sub-part of the iterative and incremental development strategy of the EHR4CR project. The basic idea is to develop a system through repeated cycles. Starting with a subset of the software requirements, the system will be iterated until the full EHR4CR platform is specified. In each iteration design modifications are made and new functional capabilities are added. In the first step we defined for each iteration one domain scenarios that is used for estimating the probable effects, as an integral part of situation analysis and long-range planning and describes the entire domain, e.g. protocol feasibility. In the next step the domain scenario has been broken down into high-level ‘Usage Scenarios’ that describe the critical business interactions (the goals, motivations, inputs, steps, events, and/or actions which occur during the interaction) with enough detail to indicate their anticipated operation for the delivery, control and use of protocol feasibility services. The usage scenarios serve as context for the use cases and requirements and makes sure they are complete.

Results and Discussion: As a result six usage scenarios for protocol feasibility, 75 use cases and around 200 requirements were established and delivered in a software requirement specification (SRS) document. Achieving the full promise of the EHR4CR project requires a new systematic approach for requirements engineering that will only be enabled by increased collaboration and novel, iterative and distributed requirements engineering processes that deal with the heterogeneity of all included partners. Research has made a pronounced shift from individually oriented activities toward team-based scientific initiatives. This trend toward greater teamwork in science is paralleled by a growing emphasis on cross-disciplinary approaches to research. With this approach, more thorough collaborative requirements planning and negotiations within research infrastructures may be supported.