Member-only story
Rethinking the notion of API non-functional requirements.
In the context of API products functional requirements articulate how would an API respond given a particular request, whereas a non-functional requirement defines how soon would it response (latency), how many requests one can send at a time (scalability) et.al.
Classically speaking, a functional requirement is what a system is supposed to do and non-functional requirements define how a system is supposed to be
It is not uncommon to find as it was in the early days of the web when product managers did the upmost due diligence on defining user stories that articulate the functional requirements to death but then left the “non-functional” part to the engineering team to think about as their contribution to the project or left it to chance chance or to a number the system can currently support.
Part of this distinction also comes into being because Product Managers and their squads / SCRUM teams own elements that can impact the “functionality” of an API more than what are often categorized as “non-functional” ones which are often handled by “centralized” infrastructure teams that determine the fate of deployment of your APIs.
Hence it is quite unlikely to find an API product manager ever writing a story in their backlog that reads something like:
