A requirements document should act as one of the entry points for people getting on board with your project: it should outline the purpose of your product, who will use it, and how it can be used. Before design and development, the product team members should read it to have a clear idea of what they'll actually work on.
The context section should provide an overview of the system – why it's being built, what business goals is it trying to accomplish, and what key functionality it will deliver.
You can describe a few typical user personas, such as John the CTO, or Ann the driver, to give the readers a better chance to think about the users of the system as actual human beings and know what to expect from them.
All those things described in the Knowing the context section should also be summarized as parts of this context section, or sometimes even given separate sections in the document. The context and scope sections should provide all the...
