|
The President's coming to inspect our secret project and we spent all the funding on vodka and video games. We better come up with something quick[^]
It was broke, so I fixed it.
|
|
|
|
|
What about a secret project of "drinking vodka and playing videos game". It is a secret afterall, so expose it in anyway you want it to be.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
One can not simply satisfy the president...
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
This is not the droid I'm looking for.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
No threat to Sarah Connor yet. They should call it terminater.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
As part of my future article, I would like to put forth the question, just to gauge the understanding
Can you please describe in a line for the meaning of Requirments and Specification from your personl experience?
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
Requirements are the "what" and Specification is the "how".
|
|
|
|
|
Precisely.
/ravi
|
|
|
|
|
I agree
NKS
|
|
|
|
|
Requirements are the "WHY" and Specification is the "WHERE".
|
|
|
|
|
Are you talking about hiding the body?
|
|
|
|
|
While the first answer is a precise and a great summation of the difference I would like to add, that requirements come from the client. Specification however is created by the developer while developing the solution according to the requirements.
|
|
|
|
|
"requirements come from the client" - sounds like you have a great client, sometimes you have to guess at what they want
|
|
|
|
|
Ha, yes you are right, I should have added - if you are lucky or perhaps requirements are made up by the project manager/director. The latter is true if you are not so lucky.
|
|
|
|
|
Requirements = Hilarity.
Specification = Impossibility.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
super wrote: personl
He asked, he told ...
"If you're about to post something you wouldn't want your kid sister to read then don't post it."
|
|
|
|
|
|
For the Dilbert question: the answer is yes.
|
|
|
|
|
To me, requirements are the wish list. Specifications are what is going to be delivered.
www.davidmkelly.net
Character-based SF and more...
|
|
|
|
|
The requirements is what the software ought to do. The specification is the documented misunderstanding of the requirements.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
|
|
|
|
|
What and how?
Requirements have 2 attributes:
1. They are statements of form, fit, and/or function.
2. They are testable (by inspection, test, etc.)
Specifications are documents. They collect the known and derived requirements. In a formal environment, there may be documents addressing software requirements, hardware requirements, and / or operation requirements. Specifications contribute (as a precursor) to test plans, procedures, and reports.
As a former system's engineer, I have not seen a 'specification' that describes 'how'.
|
|
|
|
|
Actually, they're one in the same thing:
DELUSIONS
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
When comes to these two words everyone has their own experiences and opinions. A lot of people think they are one of the same, but they really are two different documents.
Requirement: User's needs, whether explicitly or implicitly stated.
Specification: Conditional boundaries to validate and satisfy user's needs.
modified 11-Feb-15 13:35pm.
|
|
|
|
|
Here is an article that touches on this. As I see it you can take a finished article and test it to verify it meets the specification. But you have to have an understanding of its use in the 'world' to validate if the requirements are met. So the specification is kind of box level description of what it will do.
If others have said the same thing I apologize. I find it an interesting distinction.
http://www.cs.virginia.edu/~jck/publications/engineering_roles_of_req_and_spec.pdf[^]
|
|
|
|
|
Both are mythical
In general I agree with the statement that requirements are the what and the spec is the how, but I would qualify it slightly;
Requirements are the what based on why (and therefore may include 'why' notes) and the spec is a rough guide to the 'how'. If your spec is detailed enough to leave not creativity/problem solving to the dev, you (almost) might as well have written the code and avoided the spec altogether.
|
|
|
|