Learning to use a system from requirements is much like learning how to drive by reading how the engine works, it's limitations and what it does, (as well as all the other components). I have done some learning by reading code, and that helps some, but it's still a similar scenario (but possibly much lower level). Of course sometimes just playing with the system helps, but there are lots of things that you don't have a clue how to do.
In my opinion, along with any set of requirements, there should be a general "Theory of operation", or a Driving manual if you will. Then people new to your organization will have a little better idea what's going on. If you don't you're just making more work for them trying to extrapolate how to use a system by what it can and cannot do.
Another thing that would be nice, is to take an approach similar to the web, if you try to enter data in and it doesn't match, try giving an example of the "type" of data you're looking for.
If you're putting in a number but it has to be range limited, then say what that range is!
Anywho, thanks for listening, I have a few interesting posts that I am preparing for my readers (you), so hang tight. They'll be here eventually.
