My first task in developing a system or software requirement is to build a diagram of the overall process. I ask the requestor to describe in his own words what the completed system would look like.
From that, I put together a diagram (using typical flowchart symbols) to show the interactions between entities (e.g., a merchant, a system, etc.) and processes (e.g., credit scoring, customer validation, etc.).
The resulting diagram (process flow) becomes the source for identifying specific requirements.
For instance, the flow depicts a retail merchant sending an authorization (for a purchase) to a system. The requirement that would be derived is the definition of the authorization request. (What data is included, what actions need to take place based on the data, etc.)
Thus, one of the resulting requirements may be "the system must be able to accept an authorization for purchase from a participating merchant." From that, another requirement would embellish on the data that's required -- what editing must occur, etc.
The "key" is to treat the diagram as a work in progress. Revise and update it on an ongoing basis so that the focus is on extracting more and more detail until the requirements become more specific and thus easier for the effected developers to understand what's necessary.
This was first published in August 2007