The Power Platform projects that go wrong at go-live usually did the obvious half of requirements gathering well. Someone sat with the business, wrote down everything the solution had to do, the screens, the fields, the workflows, the approvals, and built faithfully to that list. Then it met real usage and fell over, not because it was missing a feature, but because nobody had written down how much data it would hold, how many people would hit it at once, who was allowed to see what, or what happened when an integration it depended on went down. The functional requirements were complete. The non-functional ones were never captured, and those are the ones that decide whether the architecture holds.
This is the discipline the Solution Architect role exists to enforce, and it is the part that separates a build that demos well from one that survives production. Functional requirements tell you what to build; non-functional requirements tell you how it has to behave under real conditions, and on Power Platform the non-functional answers change the design far more than the functional ones do. So the architect's job at the start is not to design the solution. It is to capture both kinds of requirement, and to take the non-functional ones at least as seriously as the feature list.
Functional is what; non-functional is how well
The distinction is simple to state and easy to under-apply. A functional requirement is a thing the solution must do: capture a service request, route an approval, show a dashboard. A non-functional requirement is a constraint on how well it must do it: handle this many records, respond within this time, be available during these hours, enforce this access model, comply with this regulation. Both are real requirements; only one of them tends to get written down with care.
The reason non-functional requirements matter more to the architecture is that they constrain the shape of the solution, not just its contents. A request-tracking app is the same feature whether it holds a thousand records or ten million, but the design that works at a thousand collapses at ten million, so the volume requirement, not the feature, drives the data model and the query strategy. The same is true of security, availability, and the rest: each is a constraint that the architecture has to be built around from the start, and none of them shows up in a feature list. Skip them and you are designing for the demo, where the data is small, one person is testing, and nothing has failed yet.
The NFR categories teams skip
Capturing non-functional requirements well means going through the categories deliberately, because they will not surface on their own; the business talks in features, and the architect has to ask the how-well questions. The ones that most often decide a Power Platform design:
Data volume and concurrency. How many records, growing how fast, and how many users acting at once. This drives the data model, the delegation strategy in Canvas apps, and whether high-volume Dataverse operations need a different approach than the obvious one. It is the single most common non-functional gap we see, and the most expensive to retrofit.
Security and access model. Who must see what, and who must not. The access model, business units, teams, row-level security, field-level security, is architecture, not configuration you sprinkle on later, and designing it after the data model is set is painful. This has to be a requirement, captured early.
Availability and continuity. When the solution must be available, and what happens when something it depends on is not. This is the requirement that justifies a business-continuity design rather than an assumption that the cloud handles everything.
Compliance and data residency. Regulatory constraints on where data lives and how it is governed, which can dictate environment strategy and the security model, and which are not negotiable once they apply.
Integration constraints. The systems the solution must talk to, the volumes and latencies involved, and what happens when an integration is slow or down. The integration approach is an architecture decision, and it depends on these constraints.
Device and offline needs. Whether users work on specific devices or in places without connectivity, which can make offline support a hard requirement that fundamentally changes the app design rather than a nice-to-have.
Each of these can change the architecture on its own. Captured at the start, they shape a design that holds. Discovered at the end, they are rework.
Non-functional requirements are an input, not a test
The mistake that turns NFRs into go-live disasters is treating them as something you verify at the end rather than design for at the start. Performance, security, and availability are not test cases you run on a finished build; they are inputs that determine how the build should have been done. By the time you are testing whether the solution handles the real volume, the data model is already built, and if it cannot, you are not fixing a bug, you are redesigning.
So the non-functional requirements belong in discovery, alongside the functional ones and given equal weight, captured as explicit, agreed constraints the design must satisfy. This is the same lesson that governs a good solution design document in any platform: the requirements that drive the architecture, the volume, the security, the constraints, are the ones worth pinning down first, and the feature list is the easier part that everyone remembers to do anyway. An architect who leaves discovery with a complete feature list and a vague sense of the non-functionals has captured the easy half and missed the half that decides whether the thing works.
Capturing both before you design
The practical discipline is to walk out of requirements gathering with two lists, not one. The functional list of what the solution does, which the business will give you readily, and the non-functional list of the constraints it must hold under, which you have to draw out by asking the how-well questions across volume, security, availability, compliance, integration, and devices. Then you design against both, letting the non-functional constraints shape the architecture and the functional requirements fill it in.
The order matters because it is far cheaper to design for a constraint than to retrofit it. A data model built for the real volume costs the same as one built for the demo; rebuilding it later costs the project. Capture the non-functional requirements first, take them as seriously as the features, and the architecture you design will still be standing the day the data, the users, and the failures arrive all at once.
