This is fantastic if you don't mind your requirements being out of date by the time you finish writing them down. That is assuming your business stays alive lon

This is fantastic if you don't mind your requirements being out of date by the time you finish writing them down. That is assuming your business stays alive long enough. Jokes aside, I would suggest not to corrupt your mind by looking at it, unless you are responsible for a complex safety critical application (never good idea to mix complex and safety critical -- you likely have more important problem to solve) or where a single software error can cause multi-billion dollar loss (never good idea to design your application so that single error can cause huge loss -- you likely have more important problems to solve). I have seen many attempts to formalise requirements this way and they all utterly failed. Main reason being that the people who tried to implement it were not ready for the vast effort needed to actually get it done and then to maintain it as requirements inevitably change. But the more fundamental reason for all these failures was that there always have been much more important things to get done and people who pushed these tools just did not understand what is important and this usually ends in project failure.