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...

Brightkit Hands-On: One Month In

Update 9 Mar 2009: Brightkit is now HootSuite and has continued to add and improve features.

I reported on Brightkit's functionality in mid-December. I've now been using Brightkit about a month and I'm still impressed with its labeling, navigation, and information presentation. Brightkit's UI progressively reveals operations, data, and forms so they are readily available but don't overwhelm. Its designers and developers roll out UI tweaks rapidly in response to user feedback. (Some early Brightkit idiosyncracies seem to have been resolved already.) I hope to see a more compact, information-rich interface at some point, but the service's utility outweighs the remaining (minor) irritants.

Brightkit's dashboard provides immediate access to stats for recently-sent tweets and tells you if there are any pending outbound messages, new @replies, or direct messages. You can create new tweets for any of the profiles directly from the dashboard, where you can also manage Twitter profiles and editors.

The tweet form conveniently embeds link shortening. Clicking “Shrink It” shortens the link and updates the character counter. “Edit” reveals the original link.

Graphs in the sent messages list present link stats. You can sort by tweet date, create date, or author. Date range shortcuts filter for today, week, month, and year. The custom filter defaults to the endpoints of the time period you've chosen, an example of the thought put into UI details.

The list also displays tweet error alerts. Clicking them reveals the Edit Tweet form so you can reschedule – another example of Brightkit's thoughtful UI approach.

It's easy to switch profiles with any of three dashboard options. The “jump to profile” selector bypasses the dashboard. Labeled tabs and icons make each profile's content and Twitter actions readily available. “Sent” and “pending” icons provide category cues for each message - helpful when tabs scroll out of the viewport.

The feed search's “Show Examples” reveals clear translations of the simple syntax and let you run each example to preview results.

Brightkit's large type and spacious layout make it easy to learn but soon got in my way. Showing and hiding stats per tweet and jumpy scrolling make monitoring click trends a little awkward. With just three profiles and a couple dozen sent messages I'd already like to see a no-training-wheels version. Overall, though, Brightkit's UI brings its power easily to hand. For me, its utility and convenience remain compelling.

Read more...