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.