Do Meeting Requirements Really Reach Code and Tests?

"At month-end, I want to see opening, receipts, issues and closing stock for each item on one screen."

This is an implementation meeting for Microsoft Dynamics 365 Finance & Operations (D365 F&O) at a fictional manufacturing company. The inventory lead is asking for what Korean companies usually call a subulbu: an inventory movement ledger.

The consultant opens the standard Inventory transactions page in D365 to show what is there. You can see the transactions, but that is different from what the customer wants: quantities for a chosen period, totalled in a fixed format, on a single screen.

The meeting turns to which features need to be added. The hard part, though, starts after the meeting ends.

It was said clearly in the meeting, so why does the result turn out different?

On ERP implementation projects, requirements agreed in meetings get lost or reinterpreted as they are passed on into design documents, code and test cases.

Suppose, for example, that the ledger meeting set this condition: "Show a transfer between warehouses as an issue at the sending warehouse and as a receipt at the receiving warehouse."

If that condition never makes it into the design, or drops out during testing, the screen that gets built may behave differently from what the customer first asked for. The later it is found, the longer it takes to trace the cause and fix it.

More and more teams are now using AI agents to reduce this problem. Using AI to organize meeting notes and draft requirements and design documents can cut the time spent on documentation.

But writing documents faster is not enough on its own.

The questions a customer's PMO (project management office) has to check are still there.

Which meeting, and which statement, did this requirement come from? Who reviewed and approved it? Does the feature that has been developed match the approved design?

To answer those questions, JGS designed the JGS D365 F&O AI Delivery Methodology and is validating it by applying it to an internal project.

The point is not how fast AI can write a document. It is making sure the requirement confirmed at the start carries through consistently to the final deliverable, and that the whole path can be traced.

AI drafts, AI reviews, people approve

JGS divided the roles in an implementation into a working AI, a reviewing AI, and people.

First, the working AI agent analyzes meeting recordings, transcripts and existing documents, and organizes the requirements and business rules. Each item is linked to its evidence, such as the time of a statement in the meeting or a reference document.

Anything without enough evidence is not settled arbitrarily; it is marked as an assumption or as needing confirmation.

A separate reviewing AI (the Critic) then checks the result. It is designed to use a different model from the working AI, and it reviews read-only, without changing the original.

Its job is to check whether any requirement is missing, whether any rules conflict, and whether anything was added without evidence.

Of course, having one AI review another does not catch every error.

That is why the final decision is made by people.

The consultant and the developer in charge check the evidence and the review findings, and approve whether the work can move on to the next stage. Approval gates sit between the main stages so that work that has not finished review is never used as settled input for the next stage.

The source documents and their change history are managed in Git. The approved version of a document is recorded against a specific commit, and if the document changes after approval, the new version has to be reviewed and approved again.

AI supports the work and the review, but approval and accountability rest with people.

Even one ledger needs several rounds of checks

Let's look at how this method works in a real implementation.

The manufacturing meeting above is a fictional case for illustration, but the inventory movement ledger itself is a feature of the JGS Agile Package, which JGS is developing on its internal project.

The core requirement of the ledger is to show stock quantities for a period, split into opening, receipts, issues and closing.

Simply adding a screen is not enough to build that.

Detailed business rules have to be defined: which transactions count as receipts and which as issues, how transfers between warehouses are handled, and which date and inventory dimensions are used to total the quantities.

First, in the analysis stage, these requirements are compared with standard D365 features.

D365 offers a range of standard features, such as the Inventory transactions inquiry and the Inventory value report. JGS reviewed how far those features could be used, and then sorted out what was needed.

As a result, the period-based ledger format JGS defined, and totals grouped by each company's own receipt and issue types, were hard to meet in full with the standard features reviewed, so they were classified as additional development.

On the other hand, transaction detail inquiry and inventory dimension display, which existing standard features can handle, were designed to be reused.

Separating what the standard can solve from what needs additional development in this way is what a fit-gap analysis does.

Once the analysis is approved, the work moves on to design.

The ledger inquiry page and a setup page for managing receipt and issue types are designed, and transaction types that can differ from company to company are kept in setup rather than fixed in code.

The totalling rules and exceptions are then worked out from the calculation principle "closing quantity = opening quantity + receipts − issues".

Acceptance criteria, used to judge whether each rule has been built correctly, are written at the same time.

In the method, once the design is approved, the development agent writes code within the approved scope and checks the build. In the testing stage that follows, test cases are prepared from the acceptance criteria to check normal processing, exceptions, boundary values and permissions.

At every stage, what the AI produces goes through review, and the final approval and the pass decision are made by the person in charge.

Finally, the plan is to write user manuals based on features that have passed testing. On the internal project, however, the manual stage has not been applied yet.

Two requirements turned into many checks

Here is what JGS has produced for the ledger on its internal project in this way.

As of October 12, 2026	Count
Requirements	2
Business rules	20
Acceptance criteria	50
Test cases	33
Regression test cases	5

Each requirement is broken down into business rules and acceptance criteria, and each criterion is linked to the test cases that check it.

JGS manages these deliverables linked to one another by ID.

If a total in the ledger came out differently from what was expected, for example, you would start from that test case and trace back through the acceptance criteria and the design to the original requirement.

The goal is not simply to produce a lot of documents.

It is to have a structure that shows, when something goes wrong, what went wrong and at which stage it was lost.

A method still being tested, with results to be shared

JGS began applying the analysis and design stages of this method to its internal project in late September 2026. In early October, it extended the method to development and testing.

Today, the AI agents support writing and reviewing documents at each stage, and in testing they are set up to help write test cases and result summaries and to carry out a first run of the items that can be automated.

Not every feature has finished testing, though.

As of October 12, the 25 gaps managed on the internal project have finished their planned development and entered testing, but no feature has received a final pass yet. The ledger in this post is no exception: its test cases are ready, and they have not been run yet. The method and the package are updated every day, so the numbers and status in this post are as of October 12.

Because this project exists to validate the method itself, it also runs differently from a real customer project.

It is an in-house package project with no requirements meetings with a customer, so existing design documents and the consultant's instructions serve as the evidence for analysis instead of meeting recordings.

Requirements that have not been confirmed directly by a customer are also classified as assumptions. That does not mean there is no internal evidence; it separates them from the way requirements are settled on a real customer project.

The internal project is a trial, so some approval steps are simplified, and the manual stage has not been applied yet.

Through this series, JGS plans to share what worked and what needs to improve, including these differences and limits.

What matters is whether you can trust the documents AI produces

Interest in using AI on ERP implementations is growing.

But just as important as cutting the time spent writing documents is checking that what is written actually matches the business requirements, and leaving a record of the basis for that judgment.

That is where the AI delivery method JGS is developing started.

The aim is for a requirement raised in a meeting to carry through analysis, design, code and testing, and for anyone to trace who checked and approved what along the way.

Right now, JGS is validating how well this works on its internal project. As the scope widens and test results build up, we will share in concrete terms what effects and limits we found in real implementation work.

The next post takes a closer look at the analysis stage, where statements in a meeting become a requirements document linked to its evidence.

If you are curious how AI agents could help with a D365 F&O implementation or enhancement, please feel free to contact us.

JGS: designing the future of your business.

한국어 글은 네이버 블로그에서 보실 수 있습니다: blog.naver.com/jgsconsulting