As a "general rule"?

What does a requirement mean when it is stated as a "general rule"?

I find it amazing that engineers who's entire job is dealing with specs and requirements and hard facts will generate a formal requirement that "handbook xyz be followed as a general rule".

They have taught us that a requirement should be unambiguous and testable. I find this type of requirement to be neither. Anone else find this sort of irrational behaviour in engineers?

Reply to
rickman
Loading thread data ...

Until someone finds it inconvenient.

To find any group of humans consistently rational is probably umm... irrational.

Robert

Reply to
Robert Adsett

formally, legally, it means it's not a requirement

happens all the time, I keep seeing explicit ambiguity like minimize, maximum, as a goal, all the time or implicit ambiguity like when x happens y should occur (well what are the time constraints)

usually when you ask the customer to reword the requirement you find out that a new engineer just copied some text from a 20 years old requirement, and is afraid to remove the ambiguity due to a lack of knowledge or the fear of taking responsibility, or the customer just says live with it or I'll find another supplier.. .:(

Reply to
steve

Amen, Brother!

That is my #1 pet peeve about engineering! It's understandably common among junior engineers and inexcusable among seasoned engineers.

It's practically impossible to change your associates' behavior but I find one challenge to an ambiguous requirement that can win converts:

Ask the author the simple question "Ok. Can you think of a test that we can use to verify the requirement?" The author will think, then argue, then go off in denial, and if you're lucky, finally realize his mistake. That was my reaction when I was a youngin' engineer so I sympathize with the author but the behavior still needs to change.

JJS

Reply to
johnspeth

It means one of two things:

1) "If you gotta ask, the answer is no." e.g.:
2) "I know some wise-guy will find an exception."

e.g.:

Reply to
ghelbig

It means one of two things:

1) "If you gotta ask, the answer is no." e.g.:
2) "I know some wise-guy will find an exception." e.g.:
Reply to
ghelbig

It means that someone, somewhere promised to comply with the requirement, but knew that it would be inconvenient (or would interfere with legacy considerations).

Oh, that is nothing at all. It is legendary in my group that Marketing actually issued a Marketing spec for a product that states (in full) "Everything you could want in a [product type] and more". Unfortunately, the product that resulted from that is now in my sphere of responsibility.

Reply to
larwe

What it means is...

"If you do it this way, it'll work perfectly in the labs, for months even! But when you finally get it out in the field, it'll stop working right after the product has been deployed to the 4 corners of the earth, and it'll be intermittent, and only the most remote devices will exhibit failures."

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

It could be worse. We have at least one salesperson a year that insists on selling our product XYZ for a purpose that it can't fullfill. The last one actually got the customer to pay up a little money before they found out management and development were too busy with other things. I hate it when the team works against itself.

David

Reply to
David

It means use your brain and common sense. Something that is a good idea most of the time is not a good idea all the time. Engineering is about limitations and trade-offs.

as a general rule start with the obvious solutions, but do not be bound by them.

Reply to
Neil

This class of problem is discussed at length here:

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

"Should be unambiguous", eh, not "must"? Should is a weasel word! Did you ask under what circumstances a requirement does not *need* to be unambiguous, or indeed under what circumstances it is desirable for one to be ambiguous? Why do academics always live by the "do as I say, not as I do" principle?

Cheers, Alf

Reply to
Alf Katz

A general rule is one you apply unless there is more specific rule to the contrary. I don't think this is ambiguous although I agree that many might interpret casually.

Peter

Reply to
Peter Dickerson

Yep, I had one like that too, and it was signed off the same day the product was transferred to production (on a different continent) - by which time the engineering spec was hundred of pages long.

Peter

Reply to
Peter Dickerson

That sounds like something that should be honored in Dilbert!

Reply to
rickman

That sounds like something that should be honored in Dilbert!

Reply to
rickman

So then the real requirement is to "use my common sense"?

Does anyone here know what requirements are for?

Reply to
rickman

You play a good game, my friend! No, the use of the word "should" is not intended to be a weasle word. Requirements *are* to be unambiguous!

In fact, we had a review with the prime contractor today and the review standards were written very strongly. I objected to the way a requirement stated that an interface should be provided "in accordance with" the ICD that would be written from the requirements! I tried to point out that this was a cyclic reference and I was shut down by the prime saying, "we do this all the time!" Not much I can say to get past that... Of course this was not my document, so I won't have to write the test plan for it :^)

When it comes to my documents I will make sure that I pull all that sort of crap before it gets to a review. If I can't write decent documentation, I will honestly quit!

Reply to
rickman

I should read more carefully.

A requirement as a "General Rule" My guess is "I heard it should be done this way, but am not sure it will work in this case". It obviously must be clarified before continuing.

Reply to
Neil

Short answer: to justify budget and apportion blame, depending on whether it's before or after the project that you're dealing with them.

Correct answer: to give test and code a reason to match up.

If the requirement is ambiguous, test and code will match only by chance.

--Blair

Reply to
Blair P. Houghton

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.