|
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...
|
|
|
|
|
You using local times or UTC? I remember having to maintain data that had to be truncated five minutes before midnight. So I ran the job 5 minutes before midnight. It was truncating data at 7:55 AM because the data was in UTC time. I fixed the code to sleep in 1 minute increments until 11:55PM UTC was reached. Years later the whole data center was being moved to a different time zone. They had changed the code so the local times were set based on an offset from UTC times and this job would run at 11:55 PM our local time. I had screwed up by not changing the start time so it was sleeping for 16 hours (in winter) before running. I told them to fix the start time so it ran at 10:55 PM UTC time. (That way the sleep time would range from 0 to 2 hours instead of 15 - 16 hours.)
|
|
|
|
|
I have a legacy code and think of doing round trip engineering.
What kinds of benefits I can get from it? have you guys had experiences in this?
diligent hands rule....
|
|
|
|
|
My only experience with round trip engineering was a business trip from Bullhead City, AZ to Denver, CO several years ago. The greatest challenge was identifying stopping points that offered both fuel and a rest room, and determining which would be open or under construction when I arrived. The benefits, though, were immeasurable, in that I arrived both dry and well fueled at my destination, and didn't have to use a bush or walk ten miles with a gas can even once. I highly recommend it.
Seriously, who makes this crap up?
Will Rogers never met me.
|
|
|
|
|
|
Ah, unemployed patent lawyers with no scruples or knowledge. That answers everything. I guess they either sleep too soundly to hear ambulances, or aren't willing to make even that small effort toward justifying their existence. Thanks!
Will Rogers never met me.
|
|
|
|
|
"patent lawyers with no scruples or knowledge" - seems redundant to me...
According to my calculations, I should be able to retire about 5 years after I die.
|
|
|
|
|
CHill60 wrote: http://www.directorypatent.com/US/06502239.html[^] "Elements from the original source code represented by the model are placed in a meta-model, and compared to a similar meta-model of the software model."
Holy Cr@p!
That's "functionality" that I added to my spoof COBOL '99 program!
They can't possibly be taking it seriously! Everything that it achieves is nothing useful!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Too many models for me!
|
|
|
|