As I have already said, doing away with requirements altogether is a really, really good way to ensure that your project will fail in a spectacular way.
Another really good approach to being bad is to try to capture every possible requirement that anyone might ever want, ever. There are a number of advantages to this approach as compared to the “no requirements approach:
- You can create the illusion that you really know what you are doing
- You look like you are being extremely diligent
- You always look like you are extremely busy
- You create huge amounts of documentation to support the illusion that you have been both busy and diligent
Unfortunately, you may never actually get to the end of the requirements gathering process. If you do, you will probably either have missed the window of opportunity on whatever you wanted to build, or you will have produced a set of requirements so convoluted that no one will ever implement them.
On the upside, you will have greatly reduced the risk of the actual development failing, since you probably will never get there. You will save huge amounts of money on developers, as well as computers and tools for them.
So you never actually have a product to sell, or software to use. You will have done your job well, it will not look as though your project actually failed, and it will look great on your resume as you look for a new job.
| Share this post : |  |
 |
 |
 |
 |
FredSpace 