Writing requirements in the form of elementary facts

It is an established fact that specifying right requirements is the fundamental to any form of successful software development effort. The critical question is what the best way to right requirement document? In a good software requirements document, "what" should be clearly separated from "how"? Further, a good requirement document should have right mix of generalization (For reuse) and specialization (for better understanding). In a good requirement document, the core business capabilities should be clearly separated from how these capabilities are implemented. Core capabilities are business functions of a particular domain which do not change for a very long time. For example an auto insurance company should have core business capabilities of "creating policies, issuing policy, claim management, payment etc." Here is an example of  requirements specification  for payment against claim –

"System should has the capability to make on line payment against a claim"

In the above sentence core capability - payment (what) and means of payment – on line payment, has been mixed. Mixing of core capability and means to implement it give a wrong understanding of requirements and may lead to software architecture which may not be agile. A better way to write requirements is to write requirements in the form of elementary facts. Elementary fact is a fact which has been simplified to such an extent that it can no longer further simplified without loss of meaning. An elementary fact it is always expressed in a single sentence and sentence focus is on one and only one thing. Here is an example of requirements written in the form of elementary facts -

System should have capability of payments - What, G

Payment is made between two parties – What, G

System should have capability to make payment against claim – What, S

Payment against payment is made by auto insurance company to auto repair shop, S

Payment can be made by various means - How, G

Some means of payments are – How, G

On line payment S

Payment through cheque S

Payment through demand draft S

Settlement 

Settlement is a single payment against a collection of claims 

G stands for Gernalization    and S stand for Specialization

The requirements written in above manner are more likely to be understood correctly by architects/developers. The above method of writing requirements is also likely to create more generic and reusable requirements. Each elementary fact can be easily classified into what or how and generalization and specialization. An architecture developed based upon such requirement is likely to be more agile and have right mix of generalization and specialization.