"rickman" writes: [snip]
I was close to but not directly involved with a project where the contractor developed the ICDs and then proceeded to ignore them and implemented something else. The person responsible for the overall management of the project for the customer was not pleased when this came to light!
There is nothing rational about making everything a requirement and not including any suggestions/guidelines. Nor would it be rational to insist that those suggestions/guidelines be treated as requirements.
-- Guy Macon
"When will you be done?"
"Define 'done'..."
I don't agree at all. But just for the sake of argument, why do you say that?
Because not everything in a specification is necessarily a requirement. I'd like you to write a progam in C that prints hello world (a requirement) and I'd like you to write it in accordance with these coding standards as a general rule. That recognises that the coding standards may not apply to every eventuality in the code you produce, but they should be taken as a guideline.
I design pieces of electronics that have a specification as to how they should behave in detail, but part of that is the "general rule" that they should be built in a manner that is safe and employs good design and construction practices. That's usually an unspoken "general rule" but it's there, none the less. It would not be possible for a specification to detail the every last thing I should do to ensure that, much of it has to be left to my technical and professional competence.
-- Nobby Anderson
Because the following two statements are not the same, and the difference cannot be expressed in the form of a requirement:
[1] Must be no heavier than 1 kilogram; lighter than that would be desirable but is not required. [2] Must be no heavier than 1 kilogram; there is no point in making it any lighter than that.-- Guy Macon
Exactly so. As an engineer, you are not a good fit with the Taylorism that rickman advocates -- a system where the brains are seperated from the brawn, with managers doing all the thinking and the workers following instructions exactly. Great for assembly lines, not so great for designing electronics.
-- Guy Macon
The first requirement is saying that lighter is better while the second is saying that it does not matter. As a requirement they are both exactly the same, the device must weigh 1 kg or less. As a guideline the first is pointless since I have nothing to go on in any given tradeoff. If I can make it weigh 50% less, but the power consumption goes up 100%, but is still within my requirements, which do I choose?
As a requirement, the additional verbage is inappropriate. As a guideline it may or may not have value. But guildlines are not requirements... even if they are included in a requirements document, they are still not requirements.
Earlier I said that requirements are used to tell when you are done. If you have done your design and it meets all the requirements, do you keep working to optimize the design for one of the guidlines?
As requirements, guildlines are useless, as guidlines they are mostly pointless.
Is it really a "general rule" that your designs are "safe"? Isn't that a requirement?
As to the "employs good design and construction practices" guideline, we get that all the time and they are ignored. Why? Because there is no definition to the phrase. Without an unambigous criteria, it can't be verified. If you can't verify it, then it is not a requirement.
So in reality the "goodness" of the design is up to you. If there are any aspects that need to be verified, then they need to be stated in rules of some sort. There are written commercial practices just for this.
I especially find it amusing that anyone would work off of "unspoken" rules.
No separation between brains and brawn. It is just an attempt to get engineers to recognize that they are not "artists" and that what they produce is quantifiable. I am finding that even engineers who's jobs are to produce requirements are not very good at it.
I am in a relatively new job in the defense sector again after being in commercial for a number of years. I am finding that they have a lot better training and that the process of design is a lot better understood in this arena than it used to be. I have received some very good training. But the engineers are still doing the same crap that they always did and producing really bad requirements.
Before you can learn to do something better, you first have to acknowledge that you were doing a poor job. I see a lot of resistance here to the idea that requirements are not done well and that they can be done better.
the specification can and should reference industry safety requirements, it just takes a few sentences (shall meet the safety standards decribed in XYZ, class A, with the following exceptions...).
the design, the part that is up to you to do anything you want as long as it meets the spec, must employ good design and construction practices to meet a higher level spec requirement (warranty for instance).
I would get fired if I spent money implementing something that wasn't required in the spec
Does it need to be? DO you really need to have someone write down in a formal spec that your design shouldn't electrocute anyone? Or is it a "general rule" that is applied unacknowledged, to every single design anyone ever does, albeit with a greater or lesser degree of success depending on the designer. Well, except for stuff that's supposed to electrocute people, but I'd expect to see that in the spec for a tazer or electric chair.
So it'd not be a requirement in rickman world to screw a screw in tight in the absence of a spec for "tight". It'd be acceptable to leave the screws loose, simply because someone didn't write in in a spec? In my book, good construction practice would be, in the absence of a tightness spec, to do them up tight, to a tightness that seemed to me to be enough to do the job they were intended for. If it's critical enough to need a spec, it'll have one. If it isn't, it's in no way acceptable to leave them loose, though, is it?
Exactly. And exactly. The goodness of the design *is* up to me in the absence of a spec for some aspect of it. That's what being a professional engineer is all about. Another part of that is, in turn, being able to determine what aspects need to be verified, and stating that in the rules (or spec) for the design.
Then you've led a very sheltered and blinkered life, haven't you.
-- Nobby Anderson
I thought we were discussing "general rules" that were explicitly written. Even worse are the ones that go unwritten. Like many, you are forgetting what written requirements are for. You *verify* that your design meets them. If it is not written in the requirements, it does not get verified. So if you *assume* that a requirement will be met and it is never tested, you can get something other than what you want. Important things like safety are not left up to the engineer, they are verified.
You are reversing the logic. If the screw needs to be tight, then you need to have a requirement or you don't know what you will get. If it needs 5 in.oz., and you don't have a requirement, the assembler may strip it or he may tighten it enough that it seems ok, but it works loose.
You can try to make things sound silly, but if it is important, you need to have a requirement and then test it.
Yes, in the *absense*. I don't want to rely on the designer to *know* what is good and what is bad on the important parts of a product. There are parts of a design that are design, but the aspects that are important to the sucess and failure need to be requirements. Otherwise you may get a design that is not what is needed to be successful.
No, I'm just talking about what it takes to make products successful rather than random. I have seen a lot of random products.
There is nothing at all wrong with number 1, and number 1 is clearly different than number 2.
I read number one as "1 kilogram is OK, but were're willing to pay extra if it's lighter".
I admit that I haven't really followed this thread in any detail, so maybe I'm out in left field. It's not clear to me the origin of the "requirement", so I'm assuming it's from the customer and end user.
Almost all of the specifications I see, are from customers
- usually attached to a request for quote, and I work in an industry where the low bidder may or may not get the job.
When I was younger, I didn't understand why my customers didn't know as much as I do, about the things I design. Now I realize that sometimes that just have to use what knowledge they have, write a specification and get the stuff on order.
-- Hershel
Where did you get the "pay extra" part? Even if they said that, how much extra?
Well, that makes it clear, "may or may not".
Do they always get what they want?
"a requirement should be unambiguous and testable." -rickman
Can you quote the post where someone said they are?
Can you quote the post where you think you saw this? It wasn't from me; I strongly agree that many requirements are not done well and that most can be done better. What I disagree with is your opinion as to how to make them better.
Try to write in every unwritten rule and you will have a huge requirements document that sits on a shelf unused. Your's is a common error among newbie engineers. Experienced engineers try to avoid overspecifying as well as underspecifying. I myself have worked on safety-of-flight parts for aircraft and on toys for Mattel. Do you imagine that both neded the same specificity in the requirements?
No such requirement is needed in many cases. People who put in screws don't, as a general rule, undertighten or overtighten them. And that's plenty good enough for Mattel.
-- Guy Macon
If you meet the requirements, then you get paid, unless your contract lawyers screwed up.
If you exceed the requirements, especially in the directions implied by the guidelines, it can mean that you get paid a lot more. Rather than buying just the contracted number of widgets, they like it so much that they not only buy ten times as many, but also hire you to build the next generation hyperwidget.
And if you meet the requirements through specsmanship ('if you wanted it to be legally importable to the US, you should have put that in the requirements document--it won't work unless the drum is made of panda skin supported by whale baleen') it could negatively impact future contracts.
-- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)
Requirements for a product being safe will come from the legislative requirements and may not always be stated in the customers requirements. However, it would be sheer folly for an engineer not to make his product as safe as reasonably practicable.
If you expand on that a little you will see that it is as verifiable as a requirement. You may ask the question about what "employs good design and construction practices" really means. In my book that would imply that you adhere to ISO9001 and employ "current best practice". This is a term that is well understood in legal circles. I agree that these things could be stated more explicitly in the requirements.
Rules have to be "spoken" of somewhere in order that they become understood as rules.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
But you can't dispute that if a requirement is important, then it needs to be specified. Otherwise it won't be tested. Mattel has requirements which are different from NASA because the level of importance of producing a correct product is different. If the button falls off of your new toy, no big deal, they replace it. If the button falls off your space suit oxygen control, well, I guess that might be important.
You can call me a newbie, but that does not change the facts. You can leave important details to the engineer to remember or the production line to recognize as important, but then you can't verify that the design or production was done correctly. The requirements must specify everything that needs to be verified. That is a common mistake of engineers who think they know how to engineer when all they really know is design.
Yes, and that is what I said, "If the screw needs to be tight". Obviously Mattel has no special need for the screw to be tight under any definition other than the assembler's definition. So Mattel would not specify that. That is why commercial products have defects to a greater or lesser extent and get returned to the store. Rather than specify it up front, they have decided it is not important and they will handle it at the return level instead of verifying that it was done correctly up front.
I never said you specify everything, I said you need to specify what is important and needs to be verified.
Yes, it would be folly to produce a design that is not safe. That is why safety must be specified in the requirements and verified. If it is not in the requirements, how do you verify that the design will produce a safe product? Do you leave it up to the engineer? Do you leave it up to the testing group? How do you assure that the product will be a safe one?
There have been any number of commercial products that have been recalled because they cause fires. I would hazard that these products did not include any rigorous safety requirements. I believe the auto industry has also been caught not properly applying safety requirements. Is that result acceptable? Is it really ok to leave it up to the designer rather than making it a requirement and verifying it as part of the engineering process?
If ISO9001 is the requirement, then that is what should be specified, but you said that is what it means to you. I am pretty sure it means different things to others. So "good design" is an ambigous requirement. Asking for the designer to 'employ "current best practice"' is just more weasel words with the same degree of ambiguity. As soon as you say "legal circles", I realize that it has nearly no engineering meaning. *Anything* in law is subject to the interpretation of a judge or jury.
Yes, that is my point. It may be "understood", but unless you have it clearly defined, it may be "understood" in a very different way.
Every day I see the sloppiness in an area where lives can be at stake. But they keep going in the same direction because they don't have an incentive to do otherwise. We spend a great deal of time in training and then fail to follow it. Many even argue against it. I am surprised that you seem to be doing that.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.