(Un)Traceable
-
Anonymized of course:
[Requirement 1234]: If the mode input is reading something unexpected, set the mode to "Default Mode" instead of whatever the input measured.
(Note: the mode input in this case is a discrete input)
The only Implementation items that reference [Requirement 1234]:
[Implementation A]: For each of the analog inputs, if the volage is less than the specified min voltage for that input or more than the specified max voltage for that input, set a fault C for that input. (Reference: [Requirement 1234])
[Implementation B]: For each of the analog inputs, if the voltage is (bouncing around too much), set a fault S for that input. (Reference: [Requirement 1234])
[Implementation C]: For each of the analog inputs in table T, if fault F is set, also set fault G. (Reference: [Requirement 1234])
What is the point of automated traceability tools when pieces of implementation which claim to meet a requirement don't actually meet the requirement? (Yes, I realize that the above are related to determining if a particular input is outside its valid range, but setting faults has nothing to do with selecting the appropriate mode.)
This is not the only set of requirements and implementation items which exhibit this problem.
The lack of diligence on this project vexes me.
-
A little background for those of us not familiar with this sort of stuff would be nice.
-
He got a wild pointer in requirement text, that is all.
-
@too_many_usernames said:
The lack of diligence on this project vexes me.
At least they tried. I usually get requirements that effectively read "See Bob for explanation". The ones with more detail are often self-contradictory; "User listing will be sortable by last name, but this sort will not disrupt this existing order of data on the screen" or "Main grouping will be calendar month (1st through last day of month), secondary grouping will be week (Monday through Sunday). Report footer will contain the average and sum of data over all weeks for the year.".
-
@Jaime said:
I usually get requirements that effectively read "See Bob for explanation". The ones with more detail are often self-contradictory; "User listing will be sortable by last name, but this sort will not disrupt this existing order of data on the screen" or "Main grouping will be calendar month (1st through last day of month), secondary grouping will be week (Monday through Sunday). Report footer will contain the average and sum of data over all weeks for the year.".
"I want all you men to line up in a circle, alphabetically according to height, then pair off in groups of three!"
-
@Jaime said:
"User listing will be sortable by last name, but this sort will not disrupt this existing order of data on the screen"
That's because discarding the result of the sort is much more efficient than updating the display.
