You’ve checked that individual requirements are solid and follow best practice, now you want to check the set for Completeness. INCOSE’s Guide to Writing Requirements defines Completeness as “The […] requirement set for a given SOI should stand alone such that it sufficiently describes the necessary […] functionality […] without requiring other sets of […] requirements […].” That’s the definition but how do you test for completeness?
Let’s say you have two requirements forming a set:
- Req1: When [Left_Input_Device is active] AND [Right_Input_Device is active], then the SOI activate Middle_Output_Device.
- Req2: When [Left_Input_Device is inactive] AND [Right_Input_Device is inactive], then the SOI de-activate Middle_Output_Device.
Recognize that the object (Center_Output_Device) of the consequent is a binary state machine. By this I mean Center_Output_Device has to be either Active or Inactive, it can’t be neither and it can’t be both at the same time. This observation is critical.
Here’s how to test for completeness:
- Include in the set all requirements that define each possible state of the object’s statemachine. (if there are no requirements that cover a possible state of the object then you can stop here: the requirement set is not complete).
- Simplify the requirements using symbols for operands and Boolean operators. R1 becomes L ∧ R → M and R2 becomes ¬L ∧ ¬R → ¬M
- Create a truth table for the antecedents of the requirements, Let A(1) be the antecedent of Req1, etc. Generalize as A(x) as being the antecedent of requirement x.
- Determine the disjoint of the antecedents. This can be written as ∃x A(x)
- Now test ∃x A(x) to see whether it is a Tautology. If it is a Tautology then the set is Complete!
Hold on, what’s happening here?! Essentially we want to test whether there exists one antecedent that is true and whether that is the case for each row in the truth table. Only when each possible combination of antecedents are considered by the requirement set can the requirement set to be Complete!
Assuming hysterisis is not a specification objective, what this shows is that you can have a set of requirements that defining all states of the object’s state machine but still not be complete.
Check the document for two worked examples.