Use Cases: The Center of the Universe?

People have differing opinions about the role use cases play in the requirements process.

Some people think use cases are just one step in the process – something to start with. Others think that use cases bridge the gap between high-level business needs and functional requirements. Others think that use cases show how functional requirements get realized.

In my view, use cases are the center of the requirements universe.

Requirements Approaches

Of course, I’m not saying use cases are the only kind of requirement. There are other categories:

  • Declarative Based. The traditional way to define requirements. These assert conditions that the system must adhere to.
  • Model Based. These describe requirements using models that describe behavior (e.g. activity diagram) or structure (e.g. a data dictionary).
  • Prototype Based. These describe requirements using a representation of the user interface.
  • Testing Based. Test cases are another way to state the observable behavior the system must adhere to.

But at the center of these are the Use Case Based requirements. Each use case is based on a goal of an actor using the system. All other kinds of requirements should relate in some way back to one of those goals. Without the goal, there’s no need for the requirement to exist. So, in essence, use cases really are the center of the requirements universe.

What do you think?



Comments (7)

2/19/2009 11:51:04 AM #

Elena

Dear Matt,

Could you provide sources that support your ideas about requirements categories you’ve depicted in the post?
I recently read lot of books but have not encountered such elegant and simple concept, however I feel lack of knowledge in this field.
And it’s quite essential for my work to fill it as soon as possible.

Could you also recommend me any books/articles regarding possible and effective requirements capturing as addition to Use Case core?
Thank you in advance,
Lena

Elena Ukraine


2/21/2009 1:45:13 AM #

Adam Bradley

Hi Matt,

I like the model that you've described and how Use Cases fit with the other categories of specifying requirements. More often than not when I am specifying requirements I tend to use all of the categories that you have described in conjunction with Use Cases.

Thanks
Adam

Adam Bradley Australia


2/23/2009 12:04:31 PM #

Matt Terski

Hi Lena,

The concepts I present in this post aren't exactly new, but perhaps they have not been described in quite the same way. In my simple way of thinking - you create a system for the people and things who will use it. So, every requirement should somehow relate back to a goal that a user will accomplish with your system. If it doesn’t, the requirement must be unnecessary.

But each project is different. There is no single-way to specify requirements that will work every time. For each project, the amount of effort spent on each approach will vary. But as Adam points out, it’s best to have several approaches at your disposal.

There are many good requirements books available. But the two that have had the most influence on me are not new:

Advanced Use Case Modeling: Software Systems
by Frank Armour and Granville Miller

Writing Effective Use Cases
by Alistair Cockburn

Matt Terski United States


3/4/2009 7:22:19 PM #

Phillip Avelar

Matt, I like the way you explained it, I do lean more towards believing that use cases are really only the first step in the process. Development of a use case only goes so far in helping an analyst to derive the requriements, yes it is the main tool you can use to understand the system to be built, but there are many cases where a use case is not applicable. In these cases the other requirements categories might be the central tool. So I think it depends on the system you are building. So let me back up and say that maybe the first step is actually the determination of the appropriate requirement technique and then the use case if it was choosen.
Phil

Phillip Avelar United States


3/10/2009 8:35:11 AM #

Matt Terski

Interesting take, Phil. Now here's my follow-up question: In what circumstances are use cases less applicable? Are there general characteristics of some projects that make use cases less valid approach?

Matt Terski United States


3/22/2009 1:10:27 PM #

Phillip Avelar

Matt, when dealing with system to system interfaces, EDI transactions, Reports, SOA projects they do not add any value as there is no real end user interaction.  We create Software requirements specifications but in these cases we just leave out the use case portion as it is not helpful.

Phillip Avelar United States


3/23/2009 7:50:32 AM #

Matt Terski

Well, as they say, for someone who is good with a hammer, everything looks like a nail. Smile I've done a lot of work in the SOA space and thought use cases were a powerful way to drive the design. In these system-to-system scenarios, the end-user is not human, but rather another system.

But still, the interactions between the systems are based on goals and events (e.g. Submit Application). Of course, in these cases I wouldn't have a UI prototype as a next step after use cases, but rather a technical interface description (like some WSDL or messaging formats).

Matt Terski United States


Comments are closed