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.
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
This was first published in August 2007