When demands start to spread...
The larger and more complex a development project for a medical device becomes, the more information is generated.
Requirements are documented in documents, technical decisions are recorded elsewhere, and tests are documented in separate files. What initially sounds manageable becomes increasingly difficult to follow with every change.
This is particularly relevant in medical technology. Requirements do not exist in isolation, but are often linked to risks, testing, verification, validation, and further development processes.
Changing one requirement can have a parallel impact on many other areas.
Word and Excel can handle this initially, but at some point this system can no longer keep up and becomes more of an additional administrative burden.
We therefore wanted to know: How can we organize requirements engineering in a way that supports our development work and doesn't make it more complicated?
The obvious solution: An existing tool
The answer initially seemed simple: We use one of the common requirement tools available on the market.
Ultimately, there are already established solutions to the problem. We explored various software programs and realized that they are often very capable, but this also brings with it a level of complexity that was simply too much for our purposes.
For example, implementing such a system can itself become a major project. Processes need to be adapted, structures defined, and employees trained. In addition, there are sometimes high licensing and implementation costs. Therefore, these are tools more suited to large companies and corporations.
For a small to medium-sized company working on various medical technology projects, this raises a very practical question: Does a requirements tool really need to be so extensive and complex to enable good work?
For our work, the answer eventually became clear: No.
We didn't need a tool for everything.
Our problem wasn't that there were no requirement tools at all.
Our problem was that we needed a tool that suited our approach to medical technology development.
A tool that addresses the specific characteristics of our projects and company size
taken into account without being unnecessarily complex and requiring a disproportionate amount of resources.
Medical technology places special demands on development processes. Requirements must be traceable. Changes must be controlled. Tests must be related to requirements. Risks and regulatory requirements also play a role.
All of this needs to be interconnected.
At the same time, a developer should not have to spend weeks familiarizing themselves with a system before they can create or edit a requirement.
We therefore came to a rather simple conclusion:
We need a tool that's a perfect fit for us.
A tool that doesn't try to cover everything for every industry and every use case, but focuses on what is actually needed in the development of medical devices.
So we developed it ourselves.
At some point, we decided to develop our own solution.
The first step was not a finished product with a long list of features.
We started with what we ourselves needed.
The tool was primarily used in our own development processes. This allowed us to identify what works, what's missing, and where the application could be made simpler or more effective.
Then it was further developed.
New content was added. Existing features were improved. Structures were adjusted.
And then the result was used again in everyday development work.
From internal solution to product
That is precisely an important part of Medioora's story for us: We did not develop the tool because we desperately wanted to launch another software product.
We had a problem that we knew from our daily work, and we wanted a solution that worked for us.
Over time, this in-house solution evolved into a professional tool. And at some point, it became clear: Our customers need the same tool.
Other MedTech companies also work with requirements, tests, risks, and extensive documentation. The question then arises as to how this information can be meaningfully linked and kept traceable throughout the entire development process.
This led to the creation of an idea for a product with its own name, starting from an internal tool: Medioora.
Developed for medical technology
A requirements and ALM tool doesn't need to have as many features as possible. It needs to provide the right features to simplify the development process, so developers can focus on more development and less on database maintenance.
Medioora is designed to help with exactly that.
Requirements should not be scattered throughout documents, but rather managed in a structured manner and linked to relevant information in the development process.
The aim is not to unnecessarily complicate existing processes. On the contrary: the tool is intended to support the work that needs to be done anyway.
And because Medioora originated from our own MedTech development, we continue to develop it from this perspective.
Not according to the principle "What other function can we add?", but with the question:
What do developers and development teams really need in a medical technology project?