A Request for Information is easy to read as a setback. It is more useful to read it as a map. The questions a regulator asks about software R&D are remarkably consistent from one matter to the next, and they fall into two kinds. Three are about the technology: what was unknown, what was already known in the field, and who is qualified to say so. Two are about process and records: the hypothesis as written, and the evidence tied to each point. The technical three are where an independent expert belongs. The other two are your R&D advisor's craft, and the division matters, because answering a technical question with process, or a process question with technology, is how sound claims drift.
1"What is the specific unknown?"
The first question almost always points at the gap between a product and a proposition. The submission described developing a platform with certain capabilities; the regulator asks what it is about achieving those capabilities that could only be determined by experiment. The answer is never the whole platform. It is the specific technical point where published knowledge and standard practice run out, stated on its own terms. If the submission already names that point, this question is easy. If it describes features, this is where the work begins.
2"Rewrite the hypothesis at the activity level."
Software submissions tend to carry one hypothesis for the whole project, phrased as a functional objective: the system will do X under conditions Y. The regulator asks for a hypothesis per activity that sets out a technical proposition, what result is sought, and how and why it is thought achievable. Writing and structuring that hypothesis is your R&D advisor's work. What the expert contributes is the "why": the technical proposition and the state of knowledge it rests on, which is what distinguishes a hypothesis from a target.
3"What did you investigate, what did you find, and why couldn't a competent professional have known?"
This is the state-of-knowledge question, and it comes in three parts for a reason. Sources investigated shows the search was made. What was found shows what the field had already established. Why a competent professional could not have known the outcome is the conclusion the first two parts have to support. Submissions that answer only the third part, as an assertion, are asked to go back and supply the first two. The strongest answers cite the literature and the vendor documentation directly and show exactly where each stops short.
4"Who is your competent professional, and what is the evidence of their expertise?"
Regulators have become direct about this. They ask the company to describe and evidence the expertise in the relevant field that it holds internally or has engaged externally, because that is what gives the unknown-outcome claim its standing. They may also note that the response itself would be most helpful coming from a competent professional in the relevant industry who can attest to the state of knowledge. The question is an invitation. A submission that names a qualified person in the right field, and lets them speak to the technical position, answers it in full.
5"Show us which record supports which point."
Every Request for Information asks for contemporaneous records, tied to the activity and the criterion they support, with page references, and sometimes for a table summarising which document demonstrates what. This is entirely your R&D advisor's domain, and the one that most rewards their care. The expert's only contribution here is indirect: a written technical opinion is itself a document the advisor can point to when the question is the state of knowledge or the unknown outcome.
Two that appear when the software is for business use
Where the product manages a business's own operations, invoicing, scheduling, accounting and the like, expect to be asked how the activities sit outside the exclusion for software developed for internal administration. The answer turns on who the software is for and the purpose it was developed with, and it should be made explicitly rather than left to inference. And where several activities share people or infrastructure, expect a request to describe each one so that it individually meets every criterion, because each is assessed on its own.
Reading them together
Put the five in order and they form a single chain: here is the specific unknown; here is the proposition we set out to test and why we thought it achievable; here is what the field knew and where it stopped; here is the qualified person who says so; here are the records, each tied to the point it proves. The technical links (the unknown, the state of knowledge, the qualified person) are what an independent expert supplies. The structural links (the hypothesis as written, the records) are what a good R&D advisor supplies. A response built by both, each in their own lane, gives the assessor everything in the order they will look for it.
Three of the five questions are about the technology, and those are the ones that need an independent expert in the field. The other two are your advisor's. Knowing which is which is half of answering well.