When is the “flow” in a use case part of the system requirements?

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.

Comments

• Anonymous
  July 23, 2009
  I understand the problem domain you describe - however, there are organizational considerations implicit in the situation, such as; (a) often times development teams won't accept "suggested" or "general" specifications. Many times are much more comfortable working in a "do as designed" mode, unless the solution is technically not feasible or there is a belief that an alternative flow will provide a benefit - in which case discuss with the analyst who can update the spec accordingly. (b) additionally, analysts often times (certainly so in the product development arena and even in the enterprise space) ARE providing the requirements. System users may provide vague descriptions of desired functionality and from that point forward, it's the analyst's job to design the solution. This of course isn't the situation in agile environments, but the problem isn't really relevant to agile organizations in the first place.

• Anonymous
  July 23, 2009
  Hi Jason, The analyst is not usually qualified to design software, or even to design the user experience of software.  They don't have the skills and most methodologies suggest that someone else is actually responsible for the design role. Of course, you are right.  In many cases, they do.  But they should not.  Business analysts role is to collect the requirements, not design the solution.  It's a balance.  But it is a FLAW in the process if they do more.  I'm seeking to expose the flaw and provide a mechanism to correct for it. If the user has nothing more than vague requirements, the analyst can suggest better ones.  That is their job.  That is why it is such a tight-rope act.  In the "suggesting," they are designing.  I know this. That's why I point it out: the analyst needs to be honest with the developers.  His or her opinion is not better or more informed than theirs.  Teamwork requires honesty. --- Nick

• Anonymous
  August 20, 2009
  The comment has been removed

• Anonymous
  August 20, 2009
  Hi Ron, I'm not trying to dictate details of processes, because I've seen a wide variety of different ways that development teams have attempted to capture and describe requirements.  I'm only trying to point out one problem that I've typically seen with use cases.