Good Requirements - Part IV - Be Consistent

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 may be collected. Unfortunately, most of them are not discovered immediately. By itself, a requirement is neither consistent nor inconsistent. That judgment is determine 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 as 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 Telelogic DOORS, 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.)