Getting Accurate Specifications for Software?

spiffcow asks: "I design internal software for users that are largely computer-illiterate, and obtaining accurate specs for these programs has become a huge challenge. In the most recent instance, I asked for detailed specs on what an accounting program should do (i.e. accounting rules, calculation methods, and so forth), and received a Word document mock-up of an input screen, complete with useless stickers. This seems to be the norm around here. When I asked my boss (the head Sales manager) for specs, he responded saying that it was my responsibility to determine what was needed. How do I convey to the users that, in order to develop the software they want, I need detailed, accurate specs?"

Comments

Well...

[Anonymous Coward]

Step 1: Export those Word documents to HTML
Step 2: Place HTML documents on webserver, hang around on slashdot until deadline and claim all their requirements have been fulfilled.
Step 3: ???
Step 4: Fired!

accurate specs

[Patrik_AKA_RedX]

You draw a pentagram on the floor and place lit candles at each of the corners, then I'll dig up the old spell book. We should have this covered slightly after the first full moon.

Become an analyst, and hire programmers

[cerberusss]

Become an analyst, and hire programmers. Then:

1. Don't make requirements anyway. Demand that they organize and create use cases and make them code the whole thing from there.
2. 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.
3. 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.
4. 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.
5. Wait with submitting for review until you have a nice stack of documents. It's so much more economic (for you).
6. Do NOT refer to any other requirements. Just copy/paste and then make small changes.
7. Require prototypes in VB. Later, you can ask them what's taking them so long.
8. 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.
9. Make it difficult to let them get the latest requirement. Make it easy to get confused with old versions.
10. 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.
11. Make the versioning consistent with the 'Naked Gun' movies: 1, 2, 2-and-a-half, etc.
12. Never uniquely identify requirements! That way, it's too easy for analists and developers to refer and to maintain them.
13. 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.
    
    
14. Hide major requirements in a very deep nesting:
    
    123.5.1.A. This is a MAJOR requirement.
15. 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.
16. 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.
17. Include database tables in your requirements.
18. 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.
19. ???
20. Profit!!!