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

views:

109

answers:

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

Hi,

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.

So, what makes a "spec" perfect? Any consensus on this exist?

Thanks, burak ozdogan

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.

Justin Ethier 2010-06-23 14:15:11

"As clear and unambiguous as possible" isn't really helpful. The OP wants specific things to look for, not just generalized advice.

JSBangs 2010-06-23 14:21:04

+2 A:

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.

CesarGon 2010-06-23 14:35:07

+1 for terminology. This is especially important when stakeholders have a domain-specific jargon that is not shared by the software people. In scientific software, one of the things it seems we need to define every time is what the concept of a "model" means for the given project.

Daniel Pryden 2010-06-23 21:33:36

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

philippe 2010-06-23 14:37:06

+1 A:

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?

Gilbert Le Blanc 2010-06-23 14:37:30

+3 A:

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

Martin Wickman 2010-06-23 14:42:11

Agreed, unless the code you write ends up solving the wrong problem: http://twiki.org/p/pub/Codev/TWikiMarketingMeeting2008x04x21/software-engineering-explained.png

Justin Ethier 2010-06-23 19:00:34

-1 I wish I could give you -100 ;-) Seriously; I thought that by now we would've understood that specs and code work at different levels of abstraction. Also, I could argue that it is the *code* what is an approximation of the spec!

CesarGon 2010-06-24 19:16:14

Well, "spec"s are a thing of the past, something primarily used by people still clinging to the old phased waterfall method. User Stories (xp/agile) is the way forward, because they encourages communication and changing requirements by deemphasizing details. And working software (_code_) is what counts in the end.

Martin Wickman 2010-06-24 19:28:54

@Martin: maybe that's the case in your world. But try to write an avionics or a safe-critical system without a spec! Your disregard for specs makes me laugh, to be honest. It is similar to saying that you can build skyscrapers without blueprints, just because what counts in the end is steel and glass.

CesarGon 2010-06-25 18:58:57

It is well known that one should not compare software development to construction work. It is not the same thing. Development is a non-deterministic process and trying to force that into a world of blueprints and gated phases inevitable leads to failure.

Martin Wickman 2010-06-26 12:05:20

@Martin: *Some* development is non-deterministic work, and that is not necessarily a good thing. A very large community of software professionals (please see works by e.g. Parnas, or the more recent SEMAT initiative) believe that software development should be deterministic, and that, precisely, it is questionable practices such as "no specs" what make it non-deterministic. Your "it is well known that..." shows that you are still looking at a subset of the real world. But there is a much larger and diverse world out there that does not share your views.

CesarGon 2010-06-27 12:09:37

Software development is akin to "continuous innovation". Every project and product is unique and changing requirements are an integral part of the dev process. It shows that the customer is learning more about her problem and that is a good thing. You cannot change that, no-one can change that. It's just the way it is. It is of no importance if some thinkers thinks i "should be" some other way.

Martin Wickman 2010-06-27 13:40:35

@Martin: /me shrugs.

CesarGon 2010-06-27 20:11:02

ansaurus

tags:

views:

answers:

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

related questions