It is Tuesday morning at 8:12 a.m. In the conference room at VitaNext Medical, a prototype of the new infusion system sits on the table alongside two coffee mugs. A whiteboard nearby bears just three words: clearer, faster, safer.
VitaNext Medical is a medium-sized company that develops networked infusion systems for hospitals and home care. Various departments, locations, and external suppliers are working closely together on the new product generation. However, the requirements for the modular system have been managed in a scattered manner using Excel spreadsheets, Word documents, tickets, and other specialized tools thus far.
This approach worked for a long time. But with every new module, product variant, and development team involved, maintaining an overview is becoming harder. During preparations for an internal audit, it became clear just how much time is spent finding the current status of a requirement, tracking changes, and compiling associated tests.
That is why a new platform for requirements engineering needs to be implemented. Before comparing tools and scheduling presentations, however, Clara Newman, Head of Production Strategy, wants to understand what the project team needs. To that end, she is meeting with Dr. Marcus Field, the systems engineer in charge.
Together, they aim to answer the following question: What features must the new tool have, to be useful in for the project?
Clara Newman: Marcus, to put it bluntly: Why are we talking about a new tool right now and not in six months when the project has grown a bit more?
Dr. Marcus Field: Because that’s exactly when everything will become more expensive. We’re currently developing a system that integrates mechanics, embedded software, an app, the hospital backend, quality management, and regulatory approval all at once. However, as soon as multiple disciplines are tied to the same product logic, we need a common working foundation, not just for documentation, but also for thinking, coordinating, and documenting. For our regulatory approvals and certifications, we also need to demonstrate how we translate normative standards into requirements and comply with them.
Clara Newman: Specifically, what’s currently causing the most pain?
Dr. Marcus Field: Relationships become invisible as soon as they become complex. In a spreadsheet, for example, I might see the requirements listed one below the other. However, I can’t tell which function depends on which requirement, how a variant for the pediatric ward differs from one for the operating room, or where a feature inherited from a product family reappears. We don’t need a prettier version of Excel; rather, we need a system in which relationships, hierarchies, variants, and dependencies can be modeled and visualized. Otherwise, every time a change is made, we have to start from scratch and discuss what actually belongs together.
Clara Newman: Let’s stick with the topic of changes. As we all know, our favorite word is “spontaneous.” How should a tool handle that?
Dr. Marcus Field: In a way that “spontaneous” doesn’t mean “chaotic.” When a requirement changes, I want to see who made the change, why it was made, what was approved, how the two versions differ, and what basis we’re currently using to make our decision. To me, change management is not just about history; it’s also about decision-making capability. I need to be able to define a version, understand the differences, and manage approvals effectively. Otherwise, we’ll be discussing gut feelings in the steering committee instead of reliable revision versions.
Clara Newman: How far do you think the common thread needs to extend?
Dr. Marcus Field: All the way to the back end. If a hospital says, ‘The alarm needs to respond differently in this situation,’ I don’t want to send an email to three people and hope someone finds the right file. I want to see where the requirement comes from, which system function it has been translated into, what architectural decision is tied to it, what risks are involved, which test case covers it, and whether it has been verified. This end-to-end traceability is the difference between saying, “We think we’ve got it under control,” and being able to prove it.
Clara Newman: It seems like the tool is also meant to handle test management. Am I understanding that correctly?
Dr. Marcus Field: Exactly. I don’t want to wait until the end to compare the requirements against the tests. I want to incorporate acceptance criteria from the beginning and link requirements directly to test cases. If a test status changes or a requirement is modified, it should be clear immediately whether the coverage is still correct. I consider this an important safeguard against blind spots.
Clara Newman: Who is supposed to be able to work with the system? Who else should I talk to about this?
Dr. Marcus Field: Next, you should talk to the QA team and the requirements engineers. However, don’t limit yourself to just these two groups; that would be too narrow of a view. Systems engineers, developers, the testing team, the legal department, and, in some cases, even suppliers need to be able to work on the same content simultaneously, though not with the same permissions, of course. We need comments, reviews, tasks, role-based access, and direct coordination within the context of each requirement. When someone writes a review comment, it shouldn’t trigger a long email chain. If a vendor is allowed to see something, make sure they only see the intended package. No more, no less.
Clara Newman: So you want digital reviews without the usual back-and-forth?
Dr. Marcus Field: Exactly. I want to be able to assign reviewers, track decisions, and make approvals through a structured process. The less we have to switch between applications, the higher the chance that reviews will be conducted thoroughly instead of just being “ticked off the list.”
Clara Newman: Now, let’s move on to the buzzword that’s a must in any strategy session: AI. Where do you think it’s useful?
Dr. Marcus Field: It’s useful wherever it improves quality and speeds up processes without eliminating our ability to think or our sense of responsibility. I want an AI assistant that supports employees in their day-to-day work, relieves them of time-consuming routine tasks, and increases efficiency. This is especially beneficial in large projects, as it eliminates a significant amount of routine work. However, if the AI merely exists alongside the actual process and isn’t integrated into workflows, its benefits quickly fade away.
Clara Newman: Now, let’s move on to another important point. In your view, should the tool also enable visual work?
Dr. Marcus Field: Yes, absolutely. After all, we don’t just work with text. We need diagrams for the system context, requirements, and architecture. SysML diagrams are also very helpful in this regard. Furthermore, these models must remain linked to the requirements.
Clara Newman: Now, regarding the tool landscape: What would be a deal-breaker for you when it comes to integration?
Dr. Marcus Field: If the new system acts as if it were the only one in the world. That won’t work for us. We need synchronization with Jira for our development team, exchange formats like ReqIF, and the ability to generate Office documents for partners or customers. Fundamentally, we need the ability to embed information into existing workflows instead of maintaining duplicate information.
Clara Newman: What does management need at 7:30 a.m., before the first meeting starts?
Dr. Marcus Field: An overview of the current status, ideally without having to click more than once. Project managers and department heads need to immediately see where the implementation of requirements stands, where changes are concentrated, which reviews are pending, which risks are rising, and the status of test coverage. Freely configurable dashboards aren’t just nice to have; they’re a management tool. Additionally, I want live documentation, meaning I want to keep content in the system up to date and automatically generate it as a reliable specification or status document when needed.
Clara Newman: Last question. Summarizing everything from requirements to testing, including traceable changes, traceability throughout the entire development process, AI support suitable for everyday use, modeling, open integration, flexible workflows, up-to-date documentation, and a management perspective, what are the most important factors when selecting a tool?
Dr. Marcus Field: It comes down to a platform that doesn’t view requirements engineering in isolation but rather as the backbone connecting all aspects of product development.
Clara Newman: Then the path forward is clear. We’ll start researching tools right away. The best approach is to start with a webinar to get an initial overview and then explore the features in a customized demo. The tool must seamlessly integrate the areas that we currently manage only through extensive coordination, such as requirements, models, changes, reviews, risks, tests, and evaluations. All interrelationships must be consistently traceable. It’s equally important to have an experienced, long-term, reliable vendor and dedicated points of contact who understand our requirements and provide personalized support. That’s exactly what we need for the next generation of our infusion system.
Conclusion
VitaNext Medical’s requirements illustrate the capabilities necessary for a modern RE tool. It should connect information, people, and processes throughout the entire development process. The following features are particularly important:
- End-to-end traceability
Requirements can be traced from stakeholder needs to tests and verification. - Change and version management
Changes are traceable with history, justification, and approvals, and versions can be compared. - Collaboration
Teams and external partners can collaborate directly within the tool using comments, reviews, role-based access control, chat, and video conferencing. - AI-powered support
AI assists with phrasing, offers suggestions, and detects inconsistencies directly within the process. - Modeling complex relationships
Dependencies and hierarchies are modeled and presented in a visually understandable way. - Integrated test and verification management
Requirements are linked to tests and acceptance criteria from the beginning, and changes remain traceable. - Open integration
Integration with other tools via open APIs and standards, such as ReqIF. - Powerful analytics and dashboards
Up-to-date information on requirements, changes, risks, and tests is available at all times.
Can you relate to Clara and Marcus? We developed objectiF RM to address these very challenges. In our webinar, you’ll learn about the tool’s capabilities. Watch the live demo to see how objectiF RM supports these requirements.
Note: This interview was generated using artificial intelligence (AI).