At 04:12 PM 6/22/2006 -0400, Jim Fulton wrote:
I also think that the complete algorithm, including the state machine needs to be documented clearly. Your original paragraph really isn't adequate.
Only if you try to use it to interpret requirements that contain redundant information.
Maybe, you should document simple cases and refer to the full complex model for non-trivial cases.
If by non-trivial you mean cases that contain redundant information, sure. For example "<1,<2" is redundant, since "<1" implies "<2". Only the "<1" is needed, and my assumption was that a person will not write "<1, <2" unless there is also a ">" or ">=" somewhere between the "<1" and the "<2" (in ascending version order). Similarly, the only time multiple conditions for one version make sense is to have "<1,>1", but this is the same as "<>1" or "!=1". If you simply write the shortest possible requirement that expresses the version range(s) and exceptions that you do or don't want, you will find that the 1-paragraph explanation will provide you with an easy and unambiguous interpretation: scanning left to right, see if the actual version is in one of the allowed ranges, or matches a point condition. Translating this specification into an algorithm is tedious, but essentially a mechanical matter. All of your questions, on the other hand, have been assuming that there is a simple algorithm that translates into something not necessarily simple to explain. But it's the explanation that's simple, not the algorithm. Version specifications are just ranges and exceptions. Admittedly, it would have been better if Requirement had been designed to reject redundant input -- if only because it would've kept you from then asking what various redundant things *mean*. ;-) For the most part though, the implementation just ignores anything redundant.