Problem solve Get help with specific problems with your technologies, process and projects.

Gathering software requirements: The importance of sequence

Does sequence matter when you are not using use cases or process modeling techniques? Expert Sue Burk explains the importance of sequence by using a typical customer service scenario as an example.

Understanding the sequence of steps within an event is a fundamental concern of a use‑case-driven approach. But if you’re not working with use cases or process modeling techniques—such as activity diagrams, process maps or process models created with Business Process Modeling Notation (BPMN)—does sequence still matter?

Sequence is especially important for transactional systems. Recently, two friends told me about frustrating experiences with retailers. One had used an automated voice response unit to buy minutes for her prepaid mobile phone. The voice response unit indicated that her credit card charge was denied and asked my friend to speak directly to a customer service rep. The customer service rep created a new order and charged it to my friend’s credit card, and then told my friend that the credit card charge was again denied. Yet when my friend called the credit card company, she discovered that her credit card had been charged twice, once for each order that had been denied by the phone company. Eventually, she found out that the phone company’s information included a prior expiration date for her credit card. That explains why the phone company denied the charge and did not give her the minutes, but it doesn’t explain why the credit card company charged her card. Another friend ran into a similar situation when making an online renewal of a subscription for virus software.

What happened here? We don’t know for sure, but I’m guessing there were unclear requirements about sequence. Perhaps the developers thought they were fulfilling the requirements by developing and testing software that correctly – and separately – validated the customer’s credit card and requested authorization to charge the card. Maybe they did not test the combined activity to validate the card and request authorization.

So understanding sequence is still important: it helps you uncover business rules and data elements that underlie a combined or multistep activity. The underlying business rules for this example might be as follows:

  • A valid credit card is an unexpired card that was issued to the purchaser.
  • A request to authorize payment for a purchase with a credit card must be made with a valid credit card.

The rule statements are clues to the data elements you will need, such as the card’s expiration date, the purchase authorization code, the purchaser name, and the like. 

For business domains where sequence is important, such as transactional systems, you need to work with your business partners to understand sequence along with everything else you need to know (expected functionality, business rules, data, nonfunctional requirements, etc.)

How should you document sequence? You can use any technique that lets you represent a series of steps that – together, in sequence – have business value. For some organizations, use cases or process models are the technique of choice; for others, it might be scenarios derived from use cases. For still others, user stories can be strung together to specify the sequence. End-to-end test scenarios can also be created that will define the business sequence to be tested. For some organizations, these test scenarios can also double as a definition of the sequence requirement.   

Dig Deeper on Software requirements

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.