IIBA tip explains «extends» use cases

The latest IIBA® Tips & Techniques Bulletin has what seems to be a pretty useful explanation of the «extends» use case relationship. Should help BAs who don't have a programming background. If you've been struggling with what «extends» is for, see if this helps.

Tip #2: «Extend»’ing vs. «Include»’ing a Use Case

When does it make sense to split up a Use Case, and what options do I have?

«extend» and «include» are useful ways to reduce duplication and help sequence your work.

Develop an Include use case if its functionality will be required by multiple use cases. While most Include use cases tend to be fairly simple, formally capturing the details in a single Include use case allows you to avoid repeating requirements.

Examples of Include use cases: logging into a system or automating a credit check.

Extend use cases formalize an alternate flow (from one use case) into a separate use case and apply only to that other use case. A common reason to create an Extend use case is to accommodate release planning. By moving an alternate flow off into a distinct use case, it can be prioritized and tracked separately from the parent use case while still being able to show how it fits into that bigger picture.

Those looking for a good basic description of a variety of modeling techniques, including use cases, might like Scott Ambler's Agile Modeling site. There are a lot of sources for nuts-and-bolts info about use cases, but Scott also discusses how to use good judgment when deciding what models to create.

More agile BA articles: Google

Related articles by Zemanta

• Identifying, modeling and testing smart use cases (sanderhoogendoorn.org)