WRECK-quirements

"We need to create use cases!"

"No we don't - a simple data diagram accompanied by some deployment flow charts will suffice"

"What are you smoking?!  You know we can't build anything without use cases!"

"Says you... it's all the same thing"

"Nuh-uh.  Where did you learn requirements?  Buddy Bill's Bait Barn and Systems Development?"

"I'm telling the project manager you said that."

"Go ahead.  I double dog dare ya."

And so the battle rages.  At some point early in the process (and I've had people nearly come to blows whether that should be during project initiation or project planning), requirements need to be defined.  On system projects, there is more than one way to skin a cat, so the question of approaching requirements can be especially painful for all involved (not to mention the poor, naked cat).

James Taylor posted some great comments on Southwest Airlines' attempt at a new reservation management system.  Seems as though nobody is immune to all of these issues.

I've never been much of a purist when it comes to systems requirements.  I'm a systems thinker and a process guy.  My belief is that, at a baseline, I'd like to see the following ("etc." is assumed for all):

• Outputs:  Reports, files, display screens, calculation outcomes
• Inputs:  Data fields, files, links, input screens
• Transformation:  How did you turn the inputs into outputs?
• Feedback:  How can you tell if the Inputs made good outputs (error and exception reporting)
• Process:  What did people have to do to interact with this system?  Workflows?
• Other:  platforms, systems, constraints, environments, capacity

But maybe I'm oversimplifying things again.  Never mind me.  You all just pretend I wasn't here and continue in your king-of-the-hill quest to prove that your approach is the right one.  Don't forget to schedule hours upon hours of meetings, bypass relevant decision making, play a lot of politics to get your way, and sabotage anybody who doesn't think like you.  No, no, I insist.  There's really no true deadline to this project anyway.  Any target dates currently communicated were the result of an executive's drunken stupor and are totally subject to change.  Please, take your time and be sure to utterly destroy all who don't agree with you.

Did I mention that I'm thankful that my current project has a group of people who generally get along, can come to consensus quickly, and don't argue over such petty things?  But then again, I'm sure yours does, too.

Technorati Tags: use cases, requirements, project planning, initiation, flow charts, data diagrams