- Mark
- "When you have a requirement with which you don't yet know what the resulting changes are, you have some fuzziness."
- Stuart
- "Which is nice when you're stroking a kitten!"
-- The EWII project
You're working at a random company, being in-the-know about whatever people do at your random company. Some snazzy IT sales person convinced your management that the IT of your department should buy licenses and consulting for database X, application server Y or whatever software Z. Then management assigns you to write the requirements to which such a new beast should adhere to. Something inside you just... dies...
But! Don't abandon all hope. Instead, just follow these simple instructions... Inspired by the great How To Write Unmaintainable Code.
Disclaimer: this is a joke, people. Let me repeat that: this is a joke. If this makes you smile and you have a good addition, by all means add a comment.
- Don't make requirements anyway. Demand that they organize and create use cases and make them code the whole thing from there.
- If that's not possible, let a web designing agency do screen layouts. Then demand they only talk to the agency. Web designers are easy to talk with; they don't bother with stupid details. Actually, they don't bother with anything but the screen layouts.
- If you really must create requirements, create documents in PowerPoint. Make high-level, short and non-descriptive requirements. It's quite easy to design a system when you're in orbit instead of both feet on the ground.
- If you haven't driven the project into the ground, create documents in Word. Word offers fantastic opportunities! Use track changes, nested tables, extremely large tables, bizarre macros, hidden notes/comments, etc.
- Wait with submitting for review until you have a nice stack of documents. It's so much more economic (for you).
- Do NOT refer to any other requirements. Just copy/paste and then make small changes.
- Require prototypes in VB. Later, you can ask them what's taking them so long.
- They want to MoSCoW your requirements. Conduct several meetings on hot, sweaty days and slowly but surely make them understand that each and every requirement is a must-have.
- Make it difficult to let them get the latest requirement. Make it easy to get confused with old versions.
- Make circular requirements. But don't make it too obvious: make a chain of, say, 10-20 requirements and only THEN refer back to the first one.
- Make the versioning consistent with the 'Naked Gun' movies: 1, 2, 2-and-a-half, etc.
- Never uniquely identify requirements! That way, it's too easy for analists and developers to refer and to maintain them.
- Make sub-requirements that are sometimes numbered, sometimes with characters, and just for the hell of it, drop in some bullets, too! NEVER, EVER make it possible to sort the requirements in any way. Make sure to use the auto-numbering in Word, but sometimes just type them in yourself!
123. This is a major requirement.
123.1. This is a minor.
123.01A.1. Please refer to 782.5.1¾.1A.
- Hide major requirements in a very deep nesting:
123.5.1.A. This is a MAJOR requirement.
- Requirements should contradict each other, but not too obvious:
78.a7.A. A history should be kept for all items. Never should any item be
permanently deleted.
... skip a version and 300 pages ...
342.8. Wullywuz must always be permanently deleted.
- Make sure it's hard to reach you. Go live in another country. A different timezone is even better! Convince your boss to outsource to an offshore company, which is easy, since it's all the hype these days.
- Include database tables in your requirements.
- When the project has already started, make major changes. But first talk your boss into thinking that the system without that particular change is basically worthless.
- ???
- Profit!!!
- Know any more? Add a comment!