The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
HP haven't been any good for years, at least 20 to 30 by my reckoning. I really dont understand why people keep buying their crap, perhaps they're emulating the title of Stanley Kubrick's last film, Eyes Wide Shut.
And don't try telling me that their sales numbers means they are any good. Drop a turd on the footpath next to a sandwich and tell me which is the better food, based on the number of flies.
What happened yesterday to Bob's ANZAC Day uniform?
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
My VM running Windows 7 just went crazy.
A Svchost.exe started running some code which using SysInternals ProcExp I was able to determine was the nsisvc.dll. It was eating 50% of my processor on my VM which was terrible.
Yes, nsisvc.dll and there are pages of Google and there are actually a bunch of pages on Spider Monkeys too.
However, I'd like the exact info I need on spider monkeys, not just billions of search results.
Also, if you read the first few pages of results from Google you'd see that there aren't any on it eating the CPU. There are quite a few on issues with nsisvc.dll missing or whatever.
Yes Google reports there are "About 24,200 results..." for your search.
However, notice that the first page (the only one anyone ever reads -- if they even read those) is filled with those sites which report generic info for every dll you put there.
Let me know when you've read the 24,200 and you've found the right one.
I have always thought that Requirements is what the software needs to do and Specifications is the beginning of how it should do that. The software should be responsive is a requirement. All screens will either respond within 5 seconds or set the wait cursor, is a specification.
The Requirement is a description of what "the customer" wants (and is sometimes written by the customer representative, sometimes by the development team, sometimes both). It describes what the stakeholders want to pay for.
The Specification is how the developer(s) will do it (and is almost without exception written by the development team). It likely includes platform description, architectural details, technologies used, development benchmarks and milestones, and a timeline.
The Requirement describes "what" (and perhaps a little "why"). The Spec describes "how", "when" and "who".
Both documents are agreed on by both parties but are clearly from different points of view. If the project is small, the two documents might be merged into one, but the resulting document will likely see multiple versions as the project details emerge.
I've been to a few companies in my 30 years development that actually maintain the two documents separately aside from the design document. They are usually doing it for government regulations for example in health care industries.
Place I worked at attempted to merge these documents ... it was disastrous. Let the business (customer, whatever) define the requirements (with input/advice from Dev if need be - "no, you can't have a green widget with shiny bits"), but the specification is the nitty-gritty of how the software will fulfil the requirements - and you really don't want much influence from the business on that beyond agreeing that the UI fits with what they want.
Requirements are one thing; their "feasibility" is another; i.e. Requirements are usually followed up with a "feasibility study" that paint some broad costs and solutions / alternatives which require go / no-go decisions (from management / sponsors).
The requirements are WHAT. The specification is one HOW out of many possible HOWs. The docs should be kept separately because they are conceptually separate. There might be two ways to do something.
Suppose you are building cars, and the customer wants to go 0-60 in six seconds. There are many ways to do this. One way is to built a 4,000 lb car with a turbo-charged six liter V12 producing 700 horsepower. Another way is to build an enclosed four-wheeled bicycle with a 2-stroke engine developing 30 hp. Still a third is motorcycle leathers and a pair of roller skates, plus a small rocket.
The collection of requirements may limit you to a single solution of all the solutions you can imagine, but it may not. The organizations that really want to solve problems (like NASA for instance, allow their engineers to explore multiple possible solutions. This doesn't happen much in the software biz, but as competition gets fiercer, it will probably happen more.
Your question beautifully illustrates a problem with requirements. I read
The software should be responsive
and was expecting the specification to be "adapts to screen widths from 2048px down to 320px". Just goes to show that even especially as early in the process as requirements collection, it's important to clarify terminology and ensure that all statements are set in an appropriate context that everyone understands.
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!
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.
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.
Last Visit: 22-Sep-20 15:05 Last Update: 22-Sep-20 15:05