In your question you put "a bunch of word documents" on the one side and "a wiki" on the other side.
Reality is that Requirement Management Systems out there (take the top N) are there because there are hundreds, if not so thousands of requirements FOR such a requirements management system.
- A requirements solution OF COURSE should include support for different input formats like word documents or scanned white boards
- centralized access for everyone within the company and trusted outsiders
- the capability to produce traceability matrixes for impact analyses
- the capability to version and baseline certain requirements (e.g. release 2.3.1. run currently on test server A, release 2.3.4 on test server B and release 2.3.5 is currently used for training end users) (or... the set "funtionality C" will move to the next release)
- the capability to extract singular requirements from documents and store them as records / wiki entries with unique numbers, attributes (import/not important), tracebility to what RFC's, Defects were found this this.
- To support different quality and security processes which all have their hunderds of checkboxes on what the requirement solution MUST be able to do.
- To have adequate security roles support / auditing options "send me e-mail when someone touches my requirement)
- To store each RFC/Defect/Etc... with each singular requirement
- etc... etc... (etc...)
There is a certain baseline "core" set of requirements for RM system that everyone can write down in a certain amount of minutes. E.g. the set above.
But then there are the additional requirements often coming from the specific roles in an organization AND the processes that a company has standardized out (which encompass e.g. governance regulations and different quality frameworks)
So your requirements management solution contains hundreds of puzzle pieces underneath, one of the puzzle pieces could be a wiki.
you write "A team was discussing..."
In my experience the requirements FOR a RM system are often stated in the context of the role a person has in an organization and often these requirements conflict. Development Teams have total different look on requirements as e.g. operational architects or business analysts or support technicians or maintenance and theirs needs differ on what they are looking for.
An architect for instance wants to have integration with his Architect system so that he can (sandwich approach) start architecting the solutions with layers of requirements , models, requirements, models, all integrated with the solution.
So you should regard the requirements phase and selection for a RM system the same as for any other system: write down all requirements for you RM system from all partys involved and you find an enormous amount of requirements for a RM system, often not understood by other participants. Workshops etc... could help out there as well as demo's from the TOP N Gartner quadrant RM systems.
But... if you succeed in making the complete list of requirements for a RM system it becomes much clearer for all participants if a requirements wiki alone is a solution (based on the products on there)
you Write "Looking back over time, I have found issues with this approach"
On your experience with using Word Documents: it seems that you have used the Word Documents themselves to collaborate on and work on requirements. Word documents are not requirements. They are Requirement Documents. Each of them contains the atomic requirements so (also classic) RM systems extract those atomic requirements out of the word documents and store them as individual atomic REQUIREMENTS where you should collaborate on, version, etc... It would indeed be crazy to treat word documents as the requirements
but as far as I have seen no project has ever treated requirements as `a directory of requirement documents´. Ofcourse these are not THE requirements, you should always extract the individual requirements (and give them a type like use case, non functional, functional, process, release or whatever) (and have a diagram that explains the relations between the types). Furthermore ofcouse an update to an individual requirement item in your database auto updates the word document (like many RM solutions do).
Integrated approach
I think we left the stage of different tools that together form the integrated solution to support your process (requirements management, configuration management, change management, defects, etc). I think we are at the stage that most companies are looking for yet the next step: A platform to plugin all of the different puzzle pieces that seamlessly guide any role throughout a process (standardized, adjusted and auto support for all major process frameworks e.g. ITIL for maintenance, agile approaches from dev, Prince 2 for PM, whatever is standardized on, etc....) without the need for them to switch to different tools for different tasks.
wiki thinking (core)
a Requirement is anything you can trace to something else. E.g. A [house] has multiple [window]s. 90% of the people thinking on requirements treat requirements as the dictionary 'common folk' explanation of a requirement. Therefore e.g. treating 'release 1.2' as a requirement is often not understood (because the base understanding misses).
So what your actually doing is building a taxonomy.
From that thinking hypertext stems: the reason that the World Wide Web works like it does is that it can link items together. (and Wiki gives the awaited option for everyone to edit pages)
So both systems (and probably a lot of other systems) use the same approach of how people can structure information:
If we have a gazillion insects we need to put them in a taxonomy. If we have a gazillion requirements we need to put them in a taxonomy. (just to understand complexity).
Furthermore both are going through change and support changes. Both also support linking to individual items.
So it is logical that wiki comes along especially since about everyone can use a browser and knows the internet.
A wiki THEN needs to support the additional requirements as a RM system and there the problem starts: on wiki e.g. plugins need to be written for integration, to support baselining, etc... etc.. etc.. You could say that so much has to be written on top of the wiki that the wiki part in terms of pieces of code for the solution only forms a little part of that solution. On that moment the thoughts rise to make the step to a RM system that is often build from a more holistic approach. But that moment only comes when the requirements for that RM system become more and more and more.