So we're pretty good at eliciting requirements from our end customers, business division and sales/marketing. We plan projects to add/enhance features to meet those requests and prioritize tasks to meet deadlines in most profitable order.
Over time, the software product has grown, the market has changed and the original customers are less of a priority compared to some new opportunities.
So, the requirements, and therefore specifications, have changed, although all the requirements of all the stakeholders can co-exist (there are no conflicts).
We've also had some churn in the development team with people moving up, across or out and so now there's nobody who was there "at the beginning".
This has led to some customer outages where we removed what looked like unused code paths (the logic was unfamiliar to everyone) only to find the customer that needed that logic happened to run through the application a couple of months later.
We know that we could put in Unit Tests to verify that behaviour does not change accidentally (as in the case above), but this is a large code-base so it is taking time to unit-test everything.
What non-manual techniques/technologies/best-practices are available to us to verify that the software (still) meets the specifications and requirements?
I've heard agile/iterative proponents say something like "the Unit Tests are the specification". Is there any thing we could use to marry the unit tests to the original requirements?
(I saw this other post, but that is less about verification and more about usability testing)
We already do iterative development, releasing every two weeks or less.
The source base is mostly C++ on Unix. Requirements and specifications currently documented in Wiki, Word, ticketing systems and MS Project.