Once upon a time there were some people who called themselves "programmers" and they ticked me off because I'm a programmer.

These people wrote "program" code in a bizarre and utterly nauseating language called "Visual Basic." They also didn't smell like ...

... stale coffee.

People who don't smell like stale coffee and yet call themselves "programmers" bother me, unless they have a medical condition that prevents the consumption of coffee, then they probably bother me for other reasons.

Mostly I just don't understand people -- not because they are hard to understand -- I just don't understand how they can have blatant faults and not themselves see them ... i.e., they aren't like me and won't change.

Take for instance underpants. When I wear underpants, I wear them proudly. Other people don't wear their underpants proudly, or they wear them proudly, but on the outside of their other clothing.

Which brings me to today's topic: requirements.

Requirements should be specific, concise, unadorned, testable -- that is, they should be SCUT.

By specific, I mean they should describe a single function of a system and not a smorgasbord of vague, half-finished statements about dozens of functions. Oh, that's also what I mean by concise. No it isn't. Concise means they shouldn't be wordy, but should get to the point, and only one point, which is what I mean by specific. They should also be what I meant but didn't mean by concise, a better word for which would be complete, precise, and accurate -- which is actually three words. But they should be them. And they should be testable, which means that you could sit down with the system and try the function and see it work or not, which implies you could write such a test scenario, which is what I mean by testable. Unadorned means they are written without using a word processor's fancy features.

So, I guess really, we have requirements should be specific, concise, unadorned, testable, complete, accurate, and precise. That spells SCUTCAP. What else does it spell? Email me at scott@colickyclown.com and let me know what you can spell with SCUTCAP.

Here is a requirement for "underpants wearer" to illustrate my point.

Name: SR-001: System wears underpants under all other clothing.
Description: The Underpants Wearer system wears underpants immediately and only on top of its epidermis.
Simple test:
1. Enter a pair of underpants into Underpants Wearer on the Input Clothing page
2. click the "Wear Underpants" button
3. query Underpants Wearer for the status of underpants
4. observe the Location output field and verify that the z-order is "bottom"

Now, you see this is testable. Simple test is present to ensure that it is testable. We can make it virtually untestable:

Name: SR-001: System likes underpants under all other clothing.
Description: The Underpants Wearer system likes underpants immediately and only on top of its epidermis.
Simple test:
1. Enter a pair of underpants into Underpants Wearer on the Input Clothing page
2. click the "Wear Underpants" button
3. ask Underpants Wearer how it feels about the location of its underpants
4. verify .... what????

You see the problem here? Underpants wearer can't tell you how it feels about its underpants, first because it is supposed to be a computer system and computers don't wear underpants, but mostly because underpants wearers are generally a bit embarassed about this topic and can't be relied upon to actually discuss it. Even if it could tell you and it didn't like the location of its underpants, it doesn't mean anything. Liking the location of underpants is not a system function an end-user cares a lick about. It is a quality of the system, not a requirement.

Visual Basic (VB) programmers don't like requirements. They are not the kind of people who want to be confined by them. They prefer the excitement and brutal edge of coding without rules, creating software out of nothing that is usable not by their stakeholders but by people who might really need what they create -- serendipitously hitting upon the golden combination of requirements that SCUTCAP-defines THE system these people need by the "programmer's" sheer artistic genious. They like quality statements about systems, not requirements, becase VB makes it easy to code qualities of a system but extremely difficult to write a program that meets real requirements such as those that Mel would code for. VB programmers often don't have degrees in computer science or a related field. In fact, you can even have a BA in something as loathsome as Clowning and call yourself a VB programmer.

Coffee comes from beans. Coffee is called "java" sometimes. Java is a programming language with a stupid name that Java programmers have taken to the extreme of immaturity. You can write Java code as a self-contained class that meets certain conventions and voila it is a Bean.

People laugh at beans. Beans are funny. Stand up at a fancy dinner party, all somber and serious and in a solemn tone draw out "bean" firm, loud, and strong. Then sit down and resume eating. People will burst laughing.

No one gathered name requirements when Java was named. It was done by all accounts I can find in a chaotic frenzy of ecstaticly wild artistic gyrations desparately seeking to serendipitously appeal to someone somewhere out there.

Well, it doesn't appeal to me, and I'm not wearing underpants.