We're writing a requirements document for our client and need to include the use cases of the system. We're following this template:

Basic Steps
Alternate Steps
Business validations/Rules

In the Basic Steps section, should we include steps that the system performs in the back end or should we only include steps that the user directly interacts with?


Basic Steps for Search 1:

User goes to search page
User enters term
User presses search
System matches search term with database entries
System displays results


Basic Steps for Search 2:

User goes to search page
User enters term
User presses search
System displays results
  • Advice: Don't rely on Use Cases alone to capture all your requirements and business rules.
    – NoChance
    Commented Nov 30, 2011 at 23:59

2 Answers 2


"steps that the user directly interacts with" is the definition of a use case.

Things the backend may (or may not do) are an appendix to the use case. They're not testable, and they're not interactions.

A Use Case is defined pretty strictly to focus on testable behavior that's observable by one actor.

"description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful"

If there's no interaction with the central actor, that means it's not part of the use case.

An appendix or supplement can be provided in case the algorithm is (a) important and (b) required and (c) known in advance. This is rare, but can happen.

When there are complex interactions "behind the scenes", those are separate use cases with a separate collection of "behind the scenes" actors. Other systems, generally, are other actors.

A user -- a person -- doesn't see or interact with the other systems. They don't really exist. The primary system could be providing results by magic. Or they could be "canned" or static or computed in advance.

Another system -- also an actor -- doesn't see or interact with the user. The primary system sends random requests for random reasons.

  • I am going to have to disagree with you on this one. A use case is always from the perspective of an "actor". An actor could be an "end user" or could very well be another "system" as well. And all backend processes do need to be captured in terms of the functionality that they serve, IMHO
    – Jagmag
    Commented Nov 30, 2011 at 6:17
  • @InSane: When the actor is a separate system, that's a separate use case written for a separate (non-human) actor. What's important is that a use case is from the point of view of one actor. A second use case from the view of a second actor is a way to handle this.
    – S.Lott
    Commented Nov 30, 2011 at 13:18
  • hmm interesting. that's exactly what we were debating...
    – siamii
    Commented Nov 30, 2011 at 13:43
  • @bizso09: "that's exactly what we were debating"? Really? Can you clarify the question, then. The answer I provided seems pretty clear. If it doesn't provide a resolution to the debate, but just continues the debate, then please provide some clue as to what about the answer is ambiguous or unclear. Obviously, I've failed to provide a clear path forward. However. I can't see what's missing. Please provide some sense of what's ambiguous our unclear in the answer.
    – S.Lott
    Commented Nov 30, 2011 at 14:39
  • you're answer is clear. What I was referring to was what @InSane wrote. Could there be multiple actors in a use case?
    – siamii
    Commented Nov 30, 2011 at 15:09

A use case document should describe the actions taken by the user, and the resulting actions taken by the system. Each step should have a user action and the system response, so a single step would look something like this.

user clicks search button

system will display results of search, results will be paginated if over ten, results will include title and price

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.