I've sinned and I'm going to gather requirements
I really don't understand why putting together software program requirements tends to be such a hellish, ill-fated task. I just have to rant today because if I don't, I might break some piece of equipment I need to be able to work. Then again, maybe I'd finally be able to take some time off if that happened.....but I digress.
So, without further ado, here are the profiles of some Dilbert-esque characters that, despite the best efforts of recruiters, head-hunters, and interviewers, still manage to pervade almost every business I've ever built software for. I bring them to you in no particular order since, what they give me is never in any particular order either.
1. Captain Assumption
This is the person that assumes since you know computers so well, you're also an omniscient mind-reader and don't need to be told anything about anything. I realize mastering keyboard and mice skills are impressive but, really, I need you to work with me here Cap'n. If you want me to build you reports from a database that I have absolutely no knowledge of, and there are over 100 tables in the schema, and I don't have a diagram of the schema, and you won't give me access to your DBA, I'm gonna need you to give me some kind of idea which fields from which tables you want to see on your reports. No, Crystal Reports doesn't have a wizard that will tell me what you want, despite what you say it's done for you in the past. No, neither does Access. I can put on a sparkly hat with moons and stars on it if you really feel you must use a wizard to accomplish defining the report requirements...shall I?
Another thing Captain Assumption is really good at is assuming you know what all the acronyms he uses stand for as well as their meanings and translations. When he tells you that they want to be able to filter the reports by PRNS ID, CostFactor, TPE, OUB, and other arbitrary strings of letters, he assumes you know what that means. Especially if the acronyms he uses are nowhere to be found among field and table names. I mean, c'mon...the people he's worked with for 5 years now know what those acronyms mean, why don't you?
Lastly, The Good Cap'n is also really good at assuming that, regardless what he says, however misleading it may be, you understand what he meant. When Captain says "and then it will write back to the database"...he knows you understood that what he really meant was, "it will write back to a staging database that will have nightly processes run on it to transfer the data to the database you got the original data from so that it can run through a series of arbitrary business rules." Same thing. No explanation needed.
2. MatrixLearningMan
MatrixLearningMan got his name from his ability to go from a know-nothing on a subject to expert in the blink of an eye. It's as if he was plugged into The Matrix and got a download for the subject to his brain. MatrixLearningMan can be overheard making statements like, "Here's how the screen should look". Now remember, even though you've spent countless hours reading through books learning about UI design and have years of experience building user interfaces, MatrixLearningMan knows better than you. He'll tell you about UI standards you didn't even know existed because...yep, you guessed it, you're not him. Even though you know the difference between bitmap and vector graphics tools, he'll tell you how you should use MS Paint to build the preliminary mock-up screen images. And then he'll even crack open Paint and show you what he means. You can also detect the secret identity of MatrixLearningMan when you hear him say things like, "whoa...I know Kung Fu".
3. SuperFalseTechnologyTruthsBelieverMan
This guy comes from the planet Slashdotia in the OSD galaxy where they speak in a language called "31337". He will tell you how you shouldn't use a certain technology or development platform because of some rumors he read about it that were scribbled on his pirated DVD copy of Tron by a colleague that can't even spell XML. His only-known weakness is that you can stick a piece of tape under his mouse and he'll be helpless for days. Put him in a requirements meeting and he'll really destroy you. SFTTBM has been known to derail requirements meetings for hours at a time just in an effort to point out how superior PHP is to ASP.NET. Then he'll take you out for a working lunch and explain how superior tofu is to real meat. Order some tofu too, or you'll offend him. Clashing opinions aren't long for the world of SFTTBM.
4. ArbitraryRequirementsMan (a.k.a ARM)
ARM is really one of the biggest villians of them all. He'll toss around requirements like there's no tomorrow and is hard to stop. ARM will say things like, "oh...and this needs to be entirely web-based" and "this needs to meet ISO software standards" and even occasionally he'll say something like, "this needs to be unicode compliant and support multiple languages". Don't worry though, he'll save that last quote until development is almost complete. Whatever you do, don't ask ARM "why?". He doesn't need to give justification for his requirements.
I'm sure you and I both could think up some more characters but, for now, I'm done.