In the mailbag I found this nonsense, doomed to inevitable failure:

"As I get more serious about this data science stuff, it has become obvious that a windows machine is not the way to go. ... Q1: What other things should I think about and consider while shopping for a new …

Somewhere, I have a vague recollection of reading advice from someone (Bill Gates?) that it takes three versions to get things right. The context may have been a justification of the wild success of Windows 3.0.

Or, I could be just making it up.

But one thing I have …

... don't screw up cutting and pasting and the "/" vs "\" depending on unix / windows.

• No fire in the server room.
• No anthrax outbreak.
• No Zombie apocalypse …

Here's an object lesson in bad requirements writing.

"Good" is defined as a nice simple and intuitive GUI interface. I would be able to just pick symbol from a pallette and put it somewhere and the software would automatically adjust the spacing.

Some problems.

1. Noise words. Phrases like "'Good' is …

I've seen a couple of recent use case problems. The first recent failure of use cases was particularly alarming. It was a small application; a few use cases, a couple of actors.

One of the actors was labeled as "End User". Seriously. Few labels could be as vague as End …

What I knew was this: I had a program, and I was supposed to make it work. I went to a meeting, the responsibility was duly handed off to me. "Alex has it mostly done, you just need to pitch in and help finish this by Friday."

Okay.

I listened …

See So What Are Requirements? in Dr. Dobb's.

I've seen requirements done badly. I've seen some notable failures of the use case technique: almost entirely because people refuse to actually apply the technique; they refuse to write use cases from the actor's point of view. I've whined about this before …

First, let's pick the conclusion out of the middle: "However, the computation for the first and last business day of the month is trivial. So, just codify this."

Since we still lack any usable context, we're struggling with the definition of basic terms. Is this the calendar month, or the …

I recently reviewed some end user-authored use cases, and they -- of course -- reflect the way people actually work. The computer system was largely incidental to what they did.

Each use case listed half a dozen actors, had a dozen or more steps, and involved many off-line interactions among the actors …

In principle, stating a problem is a trivial exercise: someone can't do something. It can be made wonderfully complex, however. The root cause of the complexity could be a fundamental unwillingness to state the problem without including technology hints like "database" or "hierarchy" or "project management" or "change control".