Recently I had some debates about natural vs modeling language for software requirement specs, from the customer perspective. So here’s a brief sum-up of my point of view:
Writing requirements specs in (business) reader’s language mostly means natural language plus one or the other illustrative figure (and I do not mean model). Many people call this reader friendly because they do not realize how such documents fail to satisfy ‘real’ quality characteristics of requirements, like maintainability, consistency, or completeness. (as in IEEE 830). In fact the quality of a big chunk of natural language text is so hard to grasp, that most people even do not notice its incompleteness or all the inconsistencies they create when changing it, and think they are fine.
Now, is modeling, i.e. using a reduced formal language, by definition not reader friendly ? (i.e. for readers not used to it) Not at all, since the good thing about reduced languages is, that they can easily be written down in a graphical way, e.g. a simple process diagram with perhaps some branches and joins is quite intuitive, for almost everybody to read.
This is the deal for getting acceptance from not model accustomed readers: new language to learn, but easy to use the power of graphical notation. Notice that this is (only) about acceptance, i.e. readers will also benefit from the improved qualities, that are mentioned above, but other than ‘the deal’ these qualities need to be explained and require a while to take effect.
Not to mention that not everything that’s written has to be modeled and not everything that’s modeled has to be graphical.