Best conceptual thinking is that Requirements are distinct items, related to one another in various ways and therefore should be stored in a Database. Using a word processor to store requirements is the wrong way, and leads to many problems as it drives conceptual thinking that "requirements are a document" - hence this question. If you must use a word processor, keep each requirement separate, just as you would if you used Word to store contacts.
Therefore, using Outline numbering to maintain requirements is going to cause problems. Imagine trying to cross reference test and SRS and customer requirements if you change the numbers? Imagine discussing "Requirement 10.2.3.1" only to find that in yesterdays document you sent the customer it was "10.2.2.1"
Requirements are a label, and should convey little meaning. You might have one or a few short 2 to 5 letter prefix to identify the scope or unit, but by the time you have several thousand, any implied meaning should be limited. e.g. in a car you might have EM-FUEL-1234 (Engine Management, Fuel control system, requirement 1234).
Requirements should be able to be reused across projects.
Requirements must be unique, across the scope and life of the project. As a guide, changing a requirement to clarify is the same number, but to chnage it significantly, delete the old one and replace it. Using a version scheme (Append_1,_2 etc to it) can be useful.
If you must use Word to store this database, a good way is to use start and end tokens to identify requirements. If you use a unique font Style for requirements numbering, it becomes easy to highlight, search and extract them using Macros (into a database maybe) . Example Might be
#Req 1234#
Bla bla bla bla
#ReqEnd#
#Req 1234a#
Bla bla bla bla and more bla
#ReqEnd#