|
I like your answer. Though there are fewer company that practice the difference discreetly. I wondered is it because either developers
1. don't understand the difference
2. no allow the opportunity to proper practice
3. Time to market not allows it
From my 30 years experience, the more rigorous a well managed team follow process, the faster we can get a product out the door closer to allocated budget.
|
|
|
|
|
Requirements are Gathered (From the customer/consumer)
Specifications are Written (for the developers)
But the lack of either or both, is a MANAGEMENT problem IMO. Now it is either the problem of a bad manager, or a poorly managed process.
Tiny projects. You can be a little sloppy.
But lets say you are trying to replace the FAA Radar/Plane Tracking systems?
(An upgrade that has failed more than once)
You get to the point where the exactness of the Requirements "feel" like Specifications, but they are really not. Because they should not be "specifying HOW to get the job done" just what the result is Required to be!
These two are separate by definition, IMO
|
|
|
|
|
Requirements and specifications should be handled by the business team and/or product owner.
Requirements: I want a form to enter in someone's name.
Specifications: The text boxes have to be next to each other, on the same horizontal line.
These two can be in the same document or in separate documents; it all depends on how things are done at your company or with the client.
Software design document: You take the requirements and specifications, and you paraphrase them, but this time you add the detailed design specs on how to accomplish the business ask.
Theoretically, you should be able to hand a well written design document to a team and only need to answer minimal questions, or have very few subsequent follow up meetings on the SDD. I say theoretically, because theory and application are so far apart sometimes. 
Overly simplified but not by much, really.
modified 25-Apr-16 13:10pm.
|
|
|
|
|
Good point in "theory". Many software companies mixed RS. I've seen too many places where the line between requirement and specification is gray. To me that's very confusing.
A requirement is what end users tell me what they want in non-technical terms. A specification is the translation of user's terms to a bounded and testable terms. Both documents should be done separately.
|
|
|
|
|
Requirement: Coffee and Pizza!
Specification: What do you want it to do?
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Haha, I like that. It pretty much comes down to that when interfacing with customer for requirement gathering.
|
|
|
|
|
The first thing? Usually 'where's the exits in this place?'
I am not a number. I am a ... no, wait!
|
|
|
|
|
Requirement is what the customer asked for.
Specification is what you get from the manager in a group meeting with some motivational powerpoint presentation after the customer's requirement has gone through the "telephone game" from sales person to marketing to CEO to CFO to CTO to corporate manager to product manager to your manager (I'm sure I'm missing another 50 layers.)
Marc
|
|
|
|
|
Requirements are what the customer needs (this includes "internal customers"), and, in a perfect world, comprise lots of use cases.
Specifications are the technical details of how it should be built, and how it should behave.
When it's ready for shipping, met requirements are translated into documented "features", and met specifications are translated into spec sheets/data sheets for the customer.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
We have SRS (Software Requirement Specification) and HRS (Hardware Requirement Specification) documents in our company.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
This is really a confused question. To "specify" something is to "identify (something) clearly and definitely". One can specify a requirement. One can specify a design. One can specify a test. If you want a good example of how things like this are named, research the specifications (and similar documents, like plans or standards) used by the U.S. Department of Defense, or the IEEE, or ISO.
|
|
|
|
|
Requirements == needs
Specifications == deliverables
For every stated need, there is a stated deliverable.
A "Correspondence Matrix" shows the relationships.
Need Deliverable Design Code Test
Element Element Element
aN aD aDE aCE aTE
bN bD bDE bCE bTE
cN cD cDE cCE cTE
... ... ... ... ...
...in theory...
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
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
My experience has been that project creep is the great destroyer and ruins both requirements and specifications. 
A giraffe is a horse designed by a committee--- and executed by an Agile team....
|
|
|
|
|
If you have project creep, then your project should be managed using "agile" technique. Ship the first version of the product when it does something concrete, then update continuously according to the whims of the paying customer.
This is one of the great distinctions between waterfall ("design everything up front") versus agile ("start simple and manage the mission creep") styles. With agile, your customer gets something useful sooner and is generally happier in the long run since new ideas and features can be added as part of the plan.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
A Specification will generally encompass several Requirements.
|
|
|
|
|
Just a thought, but might be better to think of the documents as checkpoints along a continuum of vague to detailed.
e.g.
bid->requirements->specification->design->tests->code.
Obviously a lot of effort has to go into properly creating and maintaining these documents which is why many organizations skip over or combine these steps. Or even call them by a different names for emphasis to a given audience.
How and why would be well beyond the scope of this reply there lots of different opinions out there on what is really important in the process.
|
|
|
|
|
I have been using Visual Studio 2015 Community Edition for some time and am generally pleased with it. Yesterday I noticed Update 2 for it was available. So I set it to install with some other features (like Azure stuff).
I should have known what to expect when the upgrade took nearly 2 hours! Once it was done, I ran a brief test and it seems to work OK, although VS took a little longer to load. But then I checked my systems drive. I had 30 GB (that is thirty-giga-bytes) less free space. 
Fortunately I have lots of spare space on the drive. But 30GB for an upgrade!? Wow! VS is really getting more bloated every year.
Get me coffee and no one gets hurt!
modified 25-Apr-16 12:32pm.
|
|
|
|
|
Check out the new and improved Xamarin stuff in there.
This space for rent
|
|
|
|
|
Admittedly I don't know much about Xamarin, but I thought it existed to make you able to write .NET code everywhere? Android, MAC etc?
|
|
|
|
|
That's pretty much it - and it's free inside VS 2015 Update 2. It's a big piece of software, so it pushes sizes up.
This space for rent
|
|
|
|
|
Quote: It's a big piece of software, so it pushes sizes up
That would explain it. I suppose I better get meself an iPhone so I can start writing mobile apps. 
Get me coffee and no one gets hurt!
|
|
|
|
|
And all I want to do, is to re-engineer a simple Windows WPF desktop app into an Apple desktop app. And for all its bloated size, VS2015 Update 2 does not seem able of this simple task! Xamarin is all about iOS and Android. It does not seem to have any capability to output anything for Apple desktops. Aaaaaaaaaaaaaargggggh!
Get me coffee and no one gets hurt!
|
|
|
|
|
Quote: Check out the new and improved Xamarin stuff in there.
Improved? Really? My God, it must have been horrible before.
|
|
|
|
|
For improved, read "Free" 
This space for rent
|
|
|
|
|
Yep, same experience here...even after downloading and running from the iso, two installs on two different machines were 2+ hours each. I really haven't started using it yet, just a POC for an Android app using Xamarin, and another POC for a IVR/softphone app. I still use VS 2010 for most stuff. 
"Go forth into the source" - Neal Morse
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
