|
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.
|
|
|
|
|
Requirements are a conversation between project leads and external stake holders.
Specifications are a conversation between project leads and the developers.
Properly written, those two audiences should never have to read the others' document.
|
|
|
|
|
How about "Conception" vs. "Inception" ?
(by their respective definitions of course)
|
|
|
|
|
Requirements are what the customer needs.
Specifications are what he says he wants.
|
|
|
|
|
I remember reading a line of code, reporting to the manager there was a bug in the code. "It can't be, it's written per specification." Well, I haven't seen the specification document, could I see it? After reading it, I agreed the code exactly matched the specification. I could see the manager was satisfied that she had won me over and the code was right, so I said "It's just too bad that it doesn't do what it is supposed to do." That got her attention and after reviewing what it was actually doing, she agreed that it wasn't doing what it was supposed to do. Thank God the naming conventions were so well laid out that by just looking at the code I knew what the requirement for this segment of the code was and the specification didn't satisfy the requirement. Basically a requirement is a statement of what the code is supposed to do, the specification is the implementation plan to meet the requirement.
With a field name of Maximum_Thread_Count_Allowed, I could tell that was the requirement, the Current_Thread_Count was properly being tracked and it could generate Maximum_Thread_Count_Allowed + 2 * Thread_Count_Increment threads. All they had to do to fix it was to change a "-" to a "+" (or Vise-Versa, can't remember the formula I saw in 2005.) in the "IF" clause.
There are user requirements and implementation requirements. The first is the constraints the client puts on the code, the second are the requirements the coder has to meet so the code will properly run on the environment it is designed for. The specification should cover both sets of requirements. The user may require that older data is removed using a maintenance schedule. When the daily maintenance is run, it must complete within 24 hours or it fails the implementation requirement.
|
|
|
|
|
Working on an application to save sunrise/sunset times for various sites into a data historian. Running everything through the test application, I get a pair of values... all looks good.
Run the same coordinates and other settings through the system to be placed in production and the sunrise/sunset times are offset by 10 minutes from the test system.
Then I remembered... the data is stored with an offset from midnight... the 10 minutes was the offset and was being added to the calculated times.
Sometimes we can't see the forest for the trees...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
