I've recently finished reading "writing effective use cases" by Alistair Cockburn.

I'm looking at building a web application that sits upon 2 web services. Should I have use cases for "web application requests data from service" that corresponds to "user wants data from web application".

I see 3 options.

  1. Treat the underlying systems as actors and mention them in a whitebox fashion. E.g. user submits to webapp and webapp transmits to web service.
  2. Treat them as blackbox and write the submission use case for the user and a transmission use case for the webapp
  3. Treat it as too low of a use case, too much implementation details and just treat the webapp as a black box for use cases. Service behavior descriptions belong elsewhere.

Maybe other options. Does anyone have experience? Or a better understanding of how use cases should be written when dealing with multiple applications that are considered part of a single system.


1 Answer 1


I like Option 2.

But then you must treat the back end service as a separate system, with its own use cases, requirements, stakeholders etc.

This is probably a good idea if you think you may need to support other front ends such as iPhone and Andriod apps or even a Windows Desktop at some future time.

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