Problem?
First decide if you even have a problem. You’re saying that your teams are having conversations, which most software houses would love to hear. Conversation can lead to communication, better understanding, fewer silos, reduced cycle time, good times ahead. What’s the actual problem you’re trying to solve and *for whom * is it a problem?
This is extremely important. Don’t make work for yourself and others that nobody needs to do. If it’s just because someone in a tie is bitching about it that’s a whole different issue.
Strategy & Cost
Don’t write anything down that you don’t really need because you will create a bunch of costs. Writing it, reading it, updating it, enforcing it, testing it. What it feels like you’re trying to do here is preemptively decide on what testers should be looking at - therefore you’re building a test strategy and trying to communicate it to your testers.
If you keep this high-level you will create less cost, eg. if you tell testers to do claims testing they should be able to do that. If you tell them exactly what adverts you have up and they need to check that the product does the things in each advert then you have to supply a list of all the adverts AND you haven’t accounted for any new claims you’ve made, or you’ll forget to say to look at the website. A good way to mix this would be a charter like “Do claims testing, ensuring you look at current adverts and our website” - this keeps itself up to date much better, and allows for exploration that your testers can do. Takes the work off you and makes testing work more engaging.
Formal Requirements
I’d encourage you to fall out of love with formal requirements. Requirements are a complex web of tacit and explicit knowledge, artefacts and individual desires. You can look at formal requirements, if you have to use them, as a checklist to ensure you’ve covered your arse and try to make a quality product through understanding, communication and design.
If your teams come to some problem like “I can’t save by hitting enter” then that expectation comes from somewhere. Sometimes it’s a written requirement (“Must be able to save by hitting enter”) and sometimes is a written test (“Test that you can save by hitting enter”) and sometimes it’s from similar products, continuity in the OS, previous experience, current experience in using the product, whatever. You cannot and will not write down all the requirements, obviously, so you need to account for what your testers believe is a problem. If it’s a problem to someone who matters (e.g. your client) then it’s a threat to the value of your product. How you deal with the bureaucracies is up to how you work, but there’s probably a business person your teams can go to to determine how the design of the product should be. It has to be someone’s role to interface with both the product and the client so the client will get the product they want. This will all be part of a wider discussion. Will it take more coding time, is there some reason it’s been designed this way, should it match with the predicted expectations of computer users (e.g. Ctrl-Z usually means “undo”), and so on.
Consistency
When it comes to consistency across a product I’d say that’s more often a product of design or redesign and its communication to your teams. You cannot predict every conversation about a product - a project is a chaotic, churning beast that cannot be tied down with requirements documentation, nor a conversation about what a bug is or is not. Start high level, up in the clouds where it’s cheaper. Perhaps your development teams can take on some of the obvious decisions - just because there’s nothing in the requirements document about capitalising countries, there’s no need to insult the people of the United Arab Emirates with small letters - you don’t have that conversation you just get on and fix it.
Maybe your business people and your development people are sitting too far apart trying to communicate with opaque and limited documents rather than having a short conversation with one person who both holds the vision for the finished product and understands the concept of profit.
Perhaps you need to involve your testers at the design phase so they might ask these questions when it’s cheaper - before it’s written. Perhaps your testers need clearer understanding of what’s important to the client, or what’s important to your business. Perhaps your testers and coders need to talk more earlier on so that problems get solved as it’s written.
Perhaps your design decisions, such as supported characters, need formalising but maybe they don’t - and there may be exceptions. You may need to suddenly support or not allow a character based on use case. Perhaps what characters you support are determined by third-party software like a plugin or browser or OS you run the product on. And maybe it really doesn’t matter what characters you support, just that each time you need to use characters you can always achieve what the product needs to do - so you’re then better off having your testers look at testing with the minimum necessary characters to do a job. Numbers, + and - might be enough for phone numbers, but you need more for an address. Then you have the problem of what happens when you use an unsupported character, so you might want to test for that anyway. So a formal document is going to be hard to write, difficult to use in practice and become out of date at some point.
I suppose I’m saying if you want consistency then design with consistency, then communicate that design to the make-stuff teams.
It is hard
It’s a really complicated problem to do with communication, understanding of the product, project and client, paperwork, how much you trust your teams, how important specificity is to your client (e.g. a bank will have more to say about how you do things than a hot dog shop), and lots of other context-specific things, which is why it’s so hard to answer this, but I hope I gave you something that might help.