All Entries Tagged With: "analysis"

Time Travel for Context-free Use Cases

Yes, sometimes we BA’s need to think of creative ways to help us withhold the technology and implementation detail from our requirements.

Classic Business Analysis Articles

I was sorting through some of my bookmarks and articles I’ve accumulated over time via the Web, and found that there are a few articles that I seem to refer back to time and again.

Business Analysis Can Kill a Project (In a Good Way)

Scrapping an ill-fated project before it gets started can be as valuable as seeing a project through to successful implementation.

Congratulations, You’re Ignorant!

The more we learn, the more we realize we don’t know.

Use Case Basics: Keeping it Simple

A few simple tips for identifying and documenting use cases.

Escalation and Infinite Regression

Fancy words for pretty common ways simple projects can quickly morph into gargantuan ones.

Could requirements analysis be automated?

Could systems and software be used to take the place of the requirements analyst?

Structured Analysis & Big, Thick Documents

Great book on modeling & systems analysis and yet another critique of “big, thick documents.”

Patterns and the Evolving Business Analyst

Let’s focus on what I consider the capstone to development and “evolution” as an analyst; the ability to learn, recognize and apply patterns.

Requirements Are the Keystone

Requirements are the keystone of a successful project implementation.

Google Wave for Business Analysis

The social web is abuzz with news on the upcoming Google offering, Google Wave.

Did I Really Write That?

As I was scanning through some of my old documents, I found that I wasn’t that thrilled with a lot of my older work. Ever had that happen to you?

Accounting for Technical Debt

Hidden costs of the “quick and dirty” solution.

Economic Stimulus, Meet Business Analyst

Before you tune out, don’t worry, while “politically motivated” this is NOT going to be a post on politics, but on process and procedure – business analysis, if you will.

What do I know about “Maximizing IT Value?”

Catch my recent Requirements.net podcast interview.

Use Case Basics: Distinguishing Between Exception and Alternative Paths

A while back I was involved in a discussion during which someone commented that because exceptions are really just alternatives to the main success path, then there’s really no need to bother distinguishing them from other alternatives to the main success path.

While I knew that idea didn’t feel quite right, and there must be a good (and probably simple) response, I didn’t have one at the tip of my tongue at the time. And I admit, it wasn’t a burning issue that kept me awake at night, so I never thought much about it afterward until I came across this description of why we differentiate between the two.

The Echo, The Lie and The UML Guy

“Early on, the goal is not to be right, but rather to be wrong in interesting, illuminative ways. Oh, it’s nice to feel like a genius when you do get it right the first time; but that’s rare. Much more common is that you think that you got it right, because your customer nods and doesn’t say much, when what’s really happening is that he’s too busy and just wants this meeting to be over. So being “right” in your early Echoes can lead to a false sense of security; and trying too hard to be right right away is misplaced effort and worry. Be as correct as you can manage, but recognize the limitations of your current knowledge.”

Is the Solution Animal? Vegetable? Mineral?

Ever taken a “20 questions” approach to requirements elicitation? According to The Bitter Project Manager, there are good reasons for doing so. Querying the user/customer in 20 questions fashion helps to determine s/he wants by eliminating the things s/he doesn’t.

Vision Statement Form and Function

Form and function of the product vision statement.

The “Requirements Workbench” Concept

The idea of a “requirements workbench” is one that the guys over at Requirements.net have been consistently socializing over the past few months, and one that I have been following with interest.

Requirements.net has recently posted a Business Analyst Workbench Whitepaper and a Workbench Buyer’s Guide. To give the general gist of the workbench without stealing Req.net’s thunder, the workbench concept includes requirements management capabilities, but then goes beyond that to support the analyst through elicitation, elaboration and communication and validation activities.

How hard could it be to design the stop sign?

I recently stumbled upon this video, got a kick out of it and thoughts I’d share. It is basically a video parody for the process of designing the stop sign if the project were kicked off in 2008. There have definitely been times in my career as a BA where I’ve felt like the poor chap trying to design to the customers’ specs.

Oh.. and for geeks like me who saw this and then wondered when we really did get the stop sign, here’s an interesting link.

Quick Tip to Help Identify Use Case Actors

A few thoughts on identifying use case actors and a job-aid that may help simplify the effort.

Requirements Elicitation: Are You the Artist, or the Order-Taker?

Requirements elicitation is an art. Watching a solid business analyst efficiently identify and document business need by using a careful mix of questions is much like watching the work of any other type of artist.

Some Use Case Best Practices

As I was scanning some requirements-related blog posts a few days ago, I came across a solid post by Prashant Hegde on the topic of Use Case best practices.
He provides quite a laundry list, and I recommend that you give him a read for the rest, but I’ll include a few points that I particularly [...]

Is “Requirements Engineering” a Misnomer?

When you think of an engineer, hard skills such as the various science and technology disciplines come first to mind. It’s easy to see where one could question whether the BA has a place in the engineering tent, and I actually see that as a positive. In fact, I think that anything that chips away at the conception of business analysis as exclusively IT work is probably a good thing for the future of the BA role.

Sharing the Love – 2007-04-01

Reuse, software methodology, use case driven development, methodology.org and more.