
You’ve received feedback on your document—now it’s time to review what came back.
In general, feedback arrives fairly quickly. That’s ideal, because it prevents you from having to shift focus and then get back into the subject later.
Take note of the responses, update the status, and parse them (you can reuse the 5W1H method seen earlier in this course).
As in previous chapters, take the time to read, understand, and think critically about the responses.
You can update the document yourself if answers were given verbally or through instant messaging (if you enter an answer yourself, don’t forget to record your source’s name).
It happened to me once… (you might think I make every mistake in the book—and honestly, I can’t disagree 🙂). It was during an assignment for a major telecom group preparing a very promising new commercial offer for the summer. We kicked off the project, analyzed the specifications, reviewed the file, and found a grey area concerning the commercial name that end customers would see on their invoices: it wasn’t specified anywhere!
So naturally, we submitted our question in the file and sent it to the Business team.
During a meeting, I ran into my manager who told me, “By the way, regarding your question about the commercial name—here it is.” Great, I had the answer. I moved forward…
Except—of course—I forgot to update the file. I didn’t tell anyone the specification had been completed. The project progressed, and during testing, we had to send the invoice to the Business team for desktop publishing validation. The name that appeared was the project name, not the commercial name…
You’re probably thinking, “It’s just a name on an invoice!”
Except the commercials had already been broadcast. Changing the name was no longer possible.
To preserve the company’s image, the name had to match exactly between the ads and the invoice.
Rest assured, the story had a happy ending.
If there’s one thing to remember, it’s this: be rigorous when reporting information in the review document.
I’ve finished proofreading and all received feedback is documented. But some things are still unclear—what should I do?
If some areas remain unclear, repeat the process!
Send a second version of the document (keeping the version history).
New questions may appear once you receive the first answers, or your contact may have given a response that doesn’t address your question:
If you need to ask the same question again, rephrase it. For example:
“Can managers without VIP clearance access this screen?” ⇒ “Only managers with VIP clearance can access this screen?”
Favor affirmative statements over negative ones (you’ll sometimes need negation, but keep it as the exception).
Use the submission method recommended by your organization.
Once you receive new answers, repeat the completion/reporting process.
If new elements still contain ambiguities, you may need to begin another iteration cycle—just as you did twice already.
If you’re still not satisfied with the clarity of the responses, discuss with your team (especially the PO) whether you can reach out directly to the people who have the information—perhaps via a meeting.
At this stage of the project, you should normally have a complete, clear, and precise requirements review.
You have all the elements needed for final delivery. To do so:
Review the list of recipients;
Send them the document;
Include a short message explaining what you are communicating:
Highlight key points,
Draw attention to elements that require monitoring. In this part, it’s recommended to:
Show a corrective or follow-up action: What is being done?
Assign the action: Who is responsible?
Indicate a timeframe: When is it expected to be resolved?
Here's an example:
TO: MOA, AMOA, PO |
Hello! Please find attached the final requirements review document. Here are the key points to remember:
I would like to draw your attention to the following points:
Please contact me if you need further information. Kind regards, ME |

You received initial feedback from Édouard. He answered all your questions except one: requirement NS-7. You take note of it.
Later, while speaking with Andy, he explains that he discussed it with Édouard, who replied:
For the order details and follow-up, it’s trickier because we haven’t specified how to store this information… I’ll discuss it with the Developers and get back to you.
Your task is to consolidate the answers in the document:
transfer the information received into your file;
share and present this document (Deliverable: e-mail).
Be rigorous when updating and reporting answers. Losing information can be harmful and frustrating if it happens repeatedly.
Iterate as many times as necessary to achieve the most accurate possible requirements review (after two submissions, consider switching channels—PO, meeting, etc.).
Rephrase your question when iterating—if it wasn’t understood the first time, rephrasing often helps.
Use affirmative rather than negative sentences to make messages clearer and easier to retain.
Be aware that some grey areas may persist. In real projects, not everything is perfectly clear—make those areas as safe as possible.
You’re now ready to begin the activity that gives this Course its name: Test Strategy. But first, reinforce your knowledge by taking the Quiz that closes this part.