why is everything a use case ;)

Despite the title of my review I would like to say that first up great book.

The only criticism I would offer is that the Requirements Engineering world has unified around i* approaches [...]which are especially good at capturing and expressing non-functional requirements. I think pushing use cases at non-functional requirements is a little nieve given the semantics.

What appears to be happening in places is a merging of i* and Use Case approaches (especially at System Engineering leves)[...].

i* doesn't break the intent of what Jacobson and Ng attempt with so-called "Infrastructure Use Cases". i* is simply designed for functional and non-functional modelling - rather than trying to use a screw-driver as a hammer.

Why bother? Use case have come from the C++ world where software developers would scratch a quick "requirement" model before diving into coding. Agile methods have diluted this to "User Stories" which look remarkably like "features" as expressed by Jacobson/Ng. (In i* "features" whould be variously hard or soft goals.)

So what would be ideal? The next edition moulds Aspects, Goals (i*) and Use Cases together.

Other Reviews

• why is everything a use case ;)
• Too Abstract And Not backed by AOP implementation!
• Finally I know what Aspect Programming is for
• how use cases can lead to aspect oriented coding
• In Absentia: Unfortunate Sign of the Times