Manage Learn to apply best practices and optimize your operations.

Software requirements: A picture is worth a thousand words

By creating a diagram based on the end user's description of what the completed system would look like, you can better identify specific requirements for the software or system.

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.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.