Good Requirements Part IV – Be Consistent

This is part IV of the Good Requirements Series

Good Requirements Part I – Be Correct

Good Requirements Part II – Be Complete

Good Requirements Part III- Be Clear

If requirements are used to define how a system should function or behave (in the case of non-functional requirements, system characteristics), what does it mean when requirements conflict? OK, that was a rhetorical question. Stated plainly, the answer is that there will be confusion about what to do.


When one gathers requirements, one will generally talk to a few different people. During the course of this exercise inconsistent requirements might be collected. Unfortunately, most of them are not discovered immediately. By itself, a requirement is neither consistent nor inconsistent. That judgment is determined when requirements are examined against each other.

One way that conflicting requirements can be discovered is by ensuring that requirements are categorized properly and then reviewed category by category. Anyone who has gone through the painful exercise of ensuring consistency throughout a 100+ page MS Word
document can understand why categorization and physical grouping is helpful.

I suggest using a requirements management product such as IBM Rational Requisite Pro or Borland CalibreRM when one is working on projects. All of these products provide good requirements management capabilities such as versioning, status, approvals, and linkages (to complementary requirements).