Discovery and clashing requirements, who to bring in, what to write and who decides

The requirements document came out of three workshops with the sponsor and her two managers, and it gets signed next week. In the final walkthrough, a frontline agent mentions that many customers use the chat with a screen reader and that legal never weighed in on how long conversations are kept. Those two details change the architecture, and they surfaced by chance.

A discovery that starts with the process

Discovery doesn’t start with the technology or the model. It starts with:

• The current process: volumes, exceptions, decision points, where the time goes. Observed with the people who do the work, not just described by whoever sponsors it.
• The metric: which number has to improve and what its baseline is today. Without it there is no way to know whether the solution worked.
• The stakeholders who can stop or change the design: security, legal, compliance, the team that will run the system and the real users. If you only talked to the sponsor, discovery is incomplete.

Non-functional requirements: write them down and validate them

Non-functional requirements are the ones that change an LLM architecture the most and the ones most often forgotten:

Requirement	What it can change
Data retention and residency	where it is deployed, what gets logged, which provider or region
Accessibility	output format, interaction, testing with real users
Latency per flow	model, streaming, asynchronous or batch processing
Mandatory human review	approval flow, queues, team capacity
Audit	what is stored for each decision and for how long

They are written down explicitly, with a verifiable criterion, and validated with the right people. They are not left as “change requests after launch” or entrusted to a provider’s default settings.

When two requirements clash

Legal requires a person to review every reply before it is sent. Operations requires an answer within minutes because customers are leaving. As written, both can’t be met. These are conflicting requirements, and the architect doesn’t resolve them by quietly picking one:

1. Make the conflict explicit: put it in writing, without taking sides.
2. Quantify it: how much of the volume is routine and how much carries real risk, how long review takes, what each option costs.
3. Propose alternatives with a recommendation: for example, immediate replies for routine questions and review for special clauses and disputes.
4. Take it to the decision owner: whoever has authority over both goals, not whoever shouts loudest.
5. Record the decision as a requirement, with the reasoning.

Communicate everything in business language: cost per transaction, response time, impact of errors, measured with your own data.

The usual traps

• Signing the requirements as they were and logging the gaps as future changes.
• Asking only the sponsor to confirm points that belong to legal or security.
• Picking one of the two requirements because “legal risk outranks speed” or “the business is what matters”.
• Postponing the decision until the system is built.
• Sending a technical note full of acronyms and letting the business “decide on its own”.

In the exam

If an important requirement shows up late and from someone who wasn’t part of discovery, the answer usually combines bringing in the missing stakeholders and writing the requirement explicitly and verifiably. If two stakeholders ask for incompatible things, look for the option that quantifies the conflict, proposes a middle-ground design and takes it to whoever has the authority. Rule out the ones that decide on their own or kick it down the road.