I don''t think you want to put all the documentation for your engine in one place. I would split up the requirements document into several documents, one for each subsystem.

For example, you would have a requirements document for the EngineCore module. The use cases in this document would explain how the other modules will interact with it and how it will interact with the other modules.

For example, how is your rendering module going to access the "Task Scheduling" capability? In this case, the actor would be the "Rendering Module" and the use case would show how the actor (aka Rendering Module) would interact with the scheduler. Another example, how are Stencil Buffers going to interact with the "Memory management" capability. In this case, the "Rendering Module (or perhaps even the Stencil Buffers)" would be the actor.

Remember, an "actor" isn''t necessarily an actual person. An actor can be another subsytem or another "entity" of code that interacts with the current module.

There are a lot of interactions to think of. A game engine is no small matter. You need to know a lot of things. You have to worry about things like how the game object defined by the user is going to interact with the AI module (and perhaps the AI module requires functionality from the Physics Module). Pathfinding is going to have to know how to interact with the world and perhaps even the physics module if you are including things such as gravity, aerodynamics, or even fluid dynamics. The more functionality an engine implements, the more complicated it tends to be. Unless you can boil this down to an abstract "flyover" level, you will most likely fail. After all, there is a reason that really good engines sell for a lot of money.

I hope this helps at least a little bit.

----------------------------------

"English? English? Why would I need to know English? I''m never going to England!"

look at the orge engine! only gfx but it is well designed