There is an odd relationship between the concepts of a use case and a requirement.  A use case is a structured chunk of text, useful for understanding and evoking requirements from the end user.  It is also a way to place those requirements into context (as in “this requirements is attached to step 3 of UC41”).  There is also the “flow” itself… the order in which information is entered and the “screens” that the user enters them into.  In many cases, a use case is quite explicit about the flow, and the customers will spend a good bit of time describing that flow.  In other cases, the flow is incidental.

So, I can see three types of “requirements” that are part and parcel of use cases:

1. Declarative requirements attached to the use case: these “statements of requirement” may be implicit in the structure (as is the case with preconditions and post conditions), or may be attached to the use case itself. For example, if we are creating a workflow system, we may see a declarative requirement attached to a use case saying something like this: “When a user logs in to the workflow system, the default screen is the task list.”  The interesting thing is that this requirement could be attached to any of a dozen different use cases.  It is universally understandable.
    
2. Implicit requirements attached to a step in the use case: these are requirements for user interaction, data fields, and functionality that are implicitly stated by the description in the use case, without being declared.  For example, if we describe a use case in a workflow system where a person can “assign” a task to someone else to perform, we could see a step like this: “Step 3: from a drop-down list, select the name of the person to whom this task will be assigned, or enter their name in the text box”.  From that, we could create some declarative requirements like “users may assign a task to another user,” “the user will be presented with a list of team members to whom it is appropriate to assign a particular task, based on the task type,” and “the user may enter the name of a person to assign the task to.”
    
3. The flow of the steps in a use case:  In the use case description, the business analyst is describing a sequence of steps that the user has to go through in order to perform a specific task (or, as I like to say, complete a specific system interaction).  That sequence itself, with the implicit order of “what information is provided first” and “what information is provided next” is often created by the analyst without regard to the difficulties of asking for information in that particular order.

I specifically want to focus on type 3: implicit order.  The analyst creates this order.  In some cases, the order was created in order to “tell a story” and it is NOT a requirement from the end user… it is a requirement from the analyst.  In other words, the customer doesn’t care about the order itself.  In other cases, the customer and the analyst will carefully create that sequence of steps, focusing time and attention on the order in which information is provided.  The customer cares a great deal about the order of information (usually for valid reasons).

Here is where there is a potential for misunderstanding.  When a use case is delivered to a development team, the analyst needs to make it clear whether the order of steps is a “useful story” or a “well considered requirement.”  This indicator is missing from nearly every use case I’ve ever seen described, yet there is an interesting effect here.  Developers will read a use case and will make decisions, in code, on the basis of what they see.  Some will take all sequences in the use case as a verbatim requirement, even when it is not necessarily a requirement from the customer.  Others will look for ways to create interesting and insightful interfaces, regardless of how hard the analyst worked to create the use cases.

Testers have a problem with either option, because they are often out developing test scenarios and estimating test effort from the requirements, without consideration of the developer’s choices.

And a developer who takes the flow of a use case as a verbatim expression is the kind of developer that would never have developed the original iPhone interface, because no analyst in the world could have designed that.  The iPhone interface was developed by a design team that took the time to reconsider every aspect of user input on a touch device.  It was not dictated by a business user through a use case process.

Suggestion for improving the standard structure of use cases:

There should be an indicator of some kind attached to the use case that says one of the following options is available to the design and development teams.  Let’s call this indicator “Requirements for Flow Design” and the indicator will have one of the following values:

• Specific – the analyst and the customer carefully considered both the order of steps and the interface controls that they want to see, and the developer should follow the flow and controls described as closely as possible.
   
• Sequenced – the analyst and the customer carefully considered the sequence of information and interaction, but the customer is flexible on the interface controls that the developer may use when implementing the flow.
   
• General – the analyst and customer agree with the flow, but are willing to consider any alternative flow that meets other requirements for information and functionality.
   
• Suggested – the analyst created the flow as a story to elicit requirements.  As long as other requirements are met, the flow is optional.
   

This removes some of the guesswork about “customer intent” that is inherent in present use case design.