How does a good "spec" differ from an unclear "pray?"

I am sure everybody knows the 5Ws, a formula for getting the "full" story on something which is used in journalism.

Is there a formula like this -I mean, like that questions should be answered for example- so that a "spec" can be considered as totally complete.

Because sometimes I face some features with a spec that sounds like a "pray" more than a specification. -Well, maybe that is even the reason some prays do not come real; specs are not clear enough for the God.

S开发者_如何学Co, what makes a "spec" perfect? Any consensus on this exist?

Thanks, burak ozdogan

The only perfect specification is working, running code. Anything else is just an approximation.

Clear, shared concepts and terminology play a crucial role.

Regarding terminology, everybody needs to understand what words mean in the spec. If you are inconsistent with words or use words that the spec's audience will not recognise, then there is a risk of failure.

But that's not all. Even with perfect terminology, you need to have a clear and shared agreement on the concepts underlying the words. If differen stakeholders "cut up" reality in different ways, or, in other words, don't see the same things when they look around, and your spec fails to address this, then you are at risk too.

So, what makes a "spec" perfect?

A specification will never be perfect. A specification will be good if it answers the who, what, and when questions to everyone's satisfaction.

• Who interfaces with the system?

• What does the system need to do?

• When does the system need to do what?

Peer review also goes a long way. Once you get all stakeholders - including management - to agree on the spec, you can be confident that it is headed in the right direction.

Both functional and non-functional (aka ilities) requirements have to be considered in order to be complete.

One system that could help is FURPS (or FURPS+).

• Functionality: functional requirements
• Usability: aesthetics and consistency in the user interface
• Reliability: availability ("up time"), accuracy of calculations, and ability to recover from failures
• Performance: throughput, response time, recovery time, start-up time
• Supportability: testability, adaptability, maintainability, compatibility, - configurability, installability, scalability, and localizability

The "+" in FURPS+ to remember concerns such as:

• Design requirements
• Implementation requirements
• Interface requirements
• Physical requirements