Absolutely great video ! appreciate the effort in putting this together. Do you have any info on how to write a business requirement document and what should be the key focus. Especially when your are dealing with a customers who want every little detail from the workshop sessions we run.
This is really going to vary based on the type of product and who the stakeholders are. If the customers are extremely detail focused, that will be difficult to do in a formal requirements document on the first pass without a lot of going back and forth. Trying to do some early mockups / prototypes to get as much as possible ironed out early can help with later phases.
Typically, use cases are more often used to understand the basic ways that users will interface with the system (or how parts of the system interact with each other). This *can* be related to what the main functions are, but not necessarily. Think of use cases as being a bit more high level - something you could theoretically show to a stakeholder to discuss how the system will work. Use cases, however, are not good at specifying non-functional requirements because NFRs tend to be cross-cutting across multiple features (e.g. performance, accessibility, etc.). Use cases don't really have an effective way of expressing "all pages must be displayed withing 100 ms" or something like that.
There are definitely software systems that have a "generic" version that can then be tailored by an agency (sometimes the original developers, sometimes not) for a particular client. In that case, you effectively end up with two sets of requirements - the general requirements and then the ones for the client, potentially handled by two different teams. In the example you give (where there is a device that is configured, I'm assuming), then the base requirements tend to include the ability to do that level of customization.
