There are only two words you should never believe: “only” and “never”.

Oh, and “always”. And “every”, “each”, “none”…Yeah, that’s more than two. You didn’t believe “only”, did you? Never do that!

Whenever the stakeholders tell you an absolute, don’t believe them. Challenge them on it. Make them prove it. Make them defend it. Make them put it in writing.

Or if it’s not the right time to be challenging them, make a note of it; and then later, come back and challenge them and make them defend it and prove it and put it in writing.

To programmers, absolutes like these are mathematical statements:

• Only == 1 (or 2, or whatever follows “Only”)
• Never == 0
• Always == 1..*
• Every == 1..*
• Each == 1..*
• None == 0

And so on. But to stakeholders, as my buddy Curtis Gray says, absolutes are figures of speech, meaning “mostly” or “seldom” or “as far as I can recall”.

So developers need to nail down these assumptions. Probe and question to determine whether these are really absolutes, or only general rules. Assuming that they’re absolutes can be a major cause of unforeseen bugs. “But they told us they would never do that!” Well, they did it. The code’s broken. Everyone’s unhappy. All because you weren’t just a little more persistent during the requirements analysis stage.

In terms of UML, this commonly comes into play with multiplicity, the range of possible participants in a relationship. This can be stated as a number, a set of numbers, a range of numbers, or any combination of the above; but most commonly, you’ll see:

• 0..1
• 1
• *
• 0..*
• 1..*

In UML-speak, * stands for what mathematicians and others have commonly called n: an unspecified quantity. So if a publisher, for example, tells me that a book has 1 or more chapters and some number of authors, each of whom may be an author of multiple books, I’ll draw this picture:

But I won’t stop there. I’ll use this diagram to start asking questions, and responding to answers:

• Does a book ever have zero authors? No. Even if it’s just a compendium, we list the compiler as an author. OK, then let’s be explicit: it’s 1..* authors, because there’s never 0.
• Does an author ever have zero books? Yes, because these are our published books. Some of the authors we work with, haven’t published yet. OK, then let’s be explicit: it’s 0..* books, because there’s a chance of 0.
• Can a chapter ever be in more than 1 book? Wellllll… Yes, and no. Sometimes we make a combined volume out of two previous volumes, and the chapter then appears twice. So do you consider that the same chapter in two books, or two identical chapters? Oh, no, they’re not identical. We usually do some clean-up and additions on these combined volumes, to entice people who have the originals. Ah, if they’re not even identical, then they’re definitely two chapters, not one chapter in two books? Yep. OK, let’s leave that at 1.
• Can a book ever have 0 chapters? No, of course not. Are you sure? What about a book without any formal chapter structure? We still organize that as a single chapter. What about a book where you haven’t received any chapters from the authors yet? Oh, wait a minute, you said these were only published books. That’s right. OK, then we’ll leave this at 1..*.

Then I would redraw the picture just slightly to reflect what I learned:

I would use the diagram both to capture information and to promote further conversation. Never just draw what you “know”. And never accept an absolute at face value!