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)

Read more...

In search of great business analysis: imagination, analytical power, critical thinking skill, creativity, wisdom

Recently I've been asked how to identify and develop business analyst talent. I've found it to be an interesting question and would like to offer some observations.

The software development field has been grappling for nigh on to 50 years with problems related to requirements. For a generation the business analyst was seen as the key to solving those problems. The Agile generation saw traditional requirements practice itself as the problem, with some members advocating the radical disintermediation of software development. The business analyst community has recently begun to address the challenge by introducing greater professionalization to its practice as well as adapting its methods to the Agile world, even as an almost nihilistically pragmatic "post-Agile" movement emerges (apologies to Jason Gorman). This history begs the question of whether we, like Diogenes, ultimately will be disappointed in our quest for a solution to problems with requirements and, ultimately, successful project outcomes.

None of these approaches tries to identify what distinguishes great business analysts from the competent or the ineffective. Are BAs made or born? Can business analysts be trained, coached, or mentored to greatness? Will certification result in better requirements practice? Can using subject matter experts as BAs improve the chances for project success?

A case can be made that a handful of intangible qualities characterize truly great business analysts, whether they work under that title or some other (such as programmer/analyst, SME, product owner, user experience designer). These qualities can be refined or developed if present in raw or latent form. I am skeptical, though, that anyone can create them through training or experience. These qualities are:

• Imagination
• Analytical power
• Critical thinking
• Creativity
• Wisdom

The information space has to be imagined in order to explore it (you have to know what question to ask before you can ask it), and re-imagined as new information is discovered. The information, once gathered, has to be interpreted, restructured, and communicated so that team members can together create and craft a solution. All along the way information and ideas must be evaluated and good judgment must be exercised. Even Agile methods that use creating the solution as the exploration process, omitting the formal BA role, still often find that success relies, as does that of any approach, on the team's ability to manifest these qualities.

Frameworks and conventions serve, if these qualities are present, to reduce risk, bring stability to the effort, and help organize and communicate it. Without these intangibles frameworks and templates can actually increase risk because they create the illusion that the requirements effort was done – the “form over substance” problem.

I'd love to hear your comments as I “think out loud” in subsequent posts about whether or how

• these qualities can be developed
• various approaches, tools, and techniques intended to improve requirements practice can support practitioners and teams who (inevitably) are unevenly gifted.

Related articles by Zemanta

• Are You Agile? (feld.com)
• Uncle Bob talks Agile at Chicago ALT.NET (devlicio.us)
• Identifying, modeling and testing smart use cases (sanderhoogendoorn.org)
• Manage Project Requirements Analysis and Design (business-project-management.suite101.com)

Read more...