Ask HN: Writing a good spec
3 comments
1. Identify risks
2. Have a rough idea of the UI and workflow
3. Events: user events, external events, timers
4. Data details
5. How 2,3,4 interact
6. Deployment and upgrades (mainly if it is a desktop application)
2. Have a rough idea of the UI and workflow
3. Events: user events, external events, timers
4. Data details
5. How 2,3,4 interact
6. Deployment and upgrades (mainly if it is a desktop application)
Have actual priorities. I remember implementing a spec with several hundred or maybe thousands of req's and all but about 3 were marked High priority.
1. Don't make it too long. If you're inexperienced, keep it even shorter.
2. Discuss it with the developers halfway through, then revise.
3. Use screen mockups/wireframes.
2. Discuss it with the developers halfway through, then revise.
3. Use screen mockups/wireframes.
I've heard of folks writing a user guide before writing the program. There must be a myriad creative ways of nailing down a good spec (and a gazillion ways of writing a bad one).