How do you add additional detail to functional requirements?

The items you are mentioning are "non-functional requirements". They are called non-functional because they do not contain details which determine the business logic, they contain details about performance, availability, etc. For example, returning an error is going to require error handling, and changes in how the handling of the response works, so it is a functional requirement while returning a response within 100ms doesn't require someone to write special code to process the response so it is a non-functional requirement

I generally add an extra section into the user story, titled non-functional requirements. This gives cues to the architect early enough to make changes in architecture to ensure that non-functional requirements are met. Once a core design is in place, it can be very difficult to change the core design, so expressing the non-functional requirements up-front it best.

Keep in mind that non-functional requirements should actually be "requirements" and not "desires". Making a desire into a requirement might mean you just added a large amount of cost to the project, depending on how the requirement is worded. For example, prefer

Confirmation of the operation or its failure should return within 1 second 90% of the time.

over

Confirmation of the operating or its failure should return within 1 second.

One will cost a fraction of the other, as in the latter one, to ensure the requirement is met, you need a real-time operating system, exotic programming techniques, etc. Also consider how the system should scale. The cost of scanning 10,000 database records is not the same as the cost of scanning 10,000,000 database records. Where it is obvious that scaling is going to impact non-functional requirements, put the requirement in units.

Confirmation of the operation or its failure should return within 1 second per 10,000 database records, 90% of the time.

This is not the area to strive for more than 2 "nines" (ie. 99%) and I'd recommend one nine (90%). Each additional nine means you must test at least 10 times more (1 nine will require 100 tests, 2 nines will require 1000, 3 nines will require 10000) to obtain accurate statistics.

Likewise, this is not the place to put in "boilerplate" requirements. If one API call depends on two API calls, it won't matter if you say "each API call takes 1 second 90% of the time, because your documented non-functional requirement is wrong. By combining two API calls in a serial fashion, you need those two supporting API calls to return in roughly 1/2 a second for the service using them both to respond in 1 second.

So, my advice is to use them sparingly, and only for major interfaces that define demarcation points outside of a set of functionality, and only for those APIs where you will lose significant amounts of money if the non-functional requirement isn't met. Otherwise, you might inadvertently convert a simple $X project into a 20*$X project because in order to guarantee your non-functional requirement, they had to shift to a super-scalar architecture, consisting of a quorum for truth agreement, with a dozen or more responders, each on different hardware, instead of a simple micro-service.

Put the extra detail where it's most relevant. A specification document can change. Imagine someone decides no one cares about calculating users. How hard are you making it to remove all impacted requirements?

1. The system shall calculate the total number of users" for a web based shop
   1.1 The system shall not use more than 1GB of memory during calculation (NFR)
   1.2 The system shall calculate the total number of users in under 5 seconds (NFR)

1.1 might fight you on this. Consider changing it to "the user calculating feature shall not grow the system memory use more than 1GB when calculating." Otherwise other features that use memory will become entangled with this requirement. If that's not viable consider whether this flat memory use requirement really has anything specific to do with calculating users.

While I'm nitpicking your example, 1. is calculating the total number of currently signed in or currently signed up users?

I would caution against such specific requirements. Mainly because they become very difficult to verify. Databases tend to use as much memory as is available, so should the verification fail if there is 62Gb available, but 2Gb used? And anything involving times will depend on general workload, and the complexity of the specific task.

If things hardware and load is not defined you risk that the software is tested in a trivial environment with a handful of users and no load. And have it fail in production where these things actually matters.

There is also a risk that highly specific requirements become outdated. And this can lead to uncertainty about what requirements are actually important or not, and complacency during testing.

I would instead suggest having separate requirements dedicated to the environment and quality criteria that includes things like hardware, resource usage, load, and response times. And these should probably apply as universally as possible. This should be coupled to your testing environment, if 1Gb memory is enough you should have such a system, have tools to simulate the specified system load, automated tests to ensure response times etc.

You can include specific exceptions where needed. If you know your "count user" feature is a resource hog you might allow extra time, or place warnings or other restrictions around how it is used. But these are best used sparingly.

Where exactly such requirements will go will depend on your specific system. If it is a simple document I would try to put related requirements as close to each other as possible.

In my experience, non-functional requirements are documented in tech documentation. Mainly because of the audience. Specs are key during the system design phase. Phase that might or might not comes immediately after the requirements gathering and solution design.

Functional documentation main and most important goal is clarify the scope of the work to be done. That allows organization to make some estimations, figure a roadmap and fit the development in the current or future plan. At this point, specs are irrelevant. They are likely to become obsolete quickly as the context changes.

Mixing them up in the same documentation can be misleading too. Those implementing functionalities are not necessarily responsibles for enabling non-functional requirements. It can make developers put the focus on the wrong goal and shift from the main one which is make the system functional in the first place and then and only then, more efficient.