Categories
Rapid JAD Requirements Software Development

How To Get More of What You Need Faster

Facebooktwittergoogle_plusredditpinterestlinkedinmail

As a business analyst or system developer, do you want to get more of what you need– accurate, complete, testable requirements that meet the customer’s needs–faster?

Like any good business analyst, I often use graphical tools to explore an idea, discover logical relationships, simplify concepts, or present findings.

Consider the following:rapid-jad-2x2

This simple 2-by-2 chart plots speed and accuracy in determining functional requirements for software development.  Both are desirable goals.

It’s obvious: avoid quadrants 1-3.  Ever been there?  These are not happy places for any project.

Quadrant 4 is everyone’s goal.  Get more of what you need, faster. But how to get there? Reliably? Repeatedly? Quickly?

In my years of project experience I’ve come to rely on the four simple, actionable steps we call Rapid JAD (see quadrant 4, above).

How quickly you begin realizing benefits simply depends upon how quickly you adopt and begin practicing Rapid JAD.  Regardless of the size, complexity, duration, or project phase, start now.  Or, if you’ve already started using Rapid JAD (congratulations!), then seek opportunities to learn, reflect, improve your practice, or share with others.

You will get more of what you need, faster.  Guaranteed.

For an introduction or refresher:

Capture Now
Document Once
Visible to All
Revise Quickly

Start getting more of what you need, faster. Use the 2X2 chart, above, to plot your own success!

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Rapid JAD Requirements Uncategorized

Fllng n Th Blnks

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Fill In the Blank

By Erik Jul

If you read the title, you probably already have a sense of the topic: Filling In The Blanks.

How did you know that? In response to visual stimuli (the title), your brain did you a favor by filling in the missing letters (the vowels, in this case) in order to make sense of what you were seeing.

Take a minute to thank your brain…

…for making it easy to read an incomplete string of letters, form words, and make meaning. And for the billions of other times just today that your brain has taken much more complex and equally incomplete sensory data and rendered for you a version of the world that makes sense. Mostly.

At least, to it.

Neuro- and cognitive scientists refer to a principle of closure:

“The mind’s tendency to see complete figures or forms even if a picture is incomplete, partially hidden by other objects, or if part of the information needed to make a complete picture in our minds is missing”

Take another minute to thank your brain. It’s doing the best it can, and it certainly hopes that you appreciate it.

You see, the brain practically lives just to make sense of things, and it loves doing so in the most efficient way possible. Which often means using limited data to predict the reality that the data represent. In fact, as soon as the brain has a “good fit,” having matched sensory input against a memory bank of possibilities, it serves up it’s best offering.

Now, better take another minute to be concerned about what your brain is telling you.

And, if you are a business or requirements analyst, take a long minute to ponder the thousands of times you and others, in perfectly well-managed joint application development sessions, have thought that you understood the customer’s need based on your acceptance of the meaning that your brain provided based on limited information.

And if you are now taking a minute to wonder, “How can we decrease the chance that we are accepting in our requirements workshops as “true and complete” what our brain is providing based on incomplete information? I would completely understand.

And I would recommend practicing the Rapid JAD principles.

Now, scientifically approved.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements

I Don’t Like to Write

Facebooktwittergoogle_plusredditpinterestlinkedinmail

DoNotWrite[1]

By Erik Jul

A colleague of mine once said, “I don’t like to write, but I love having written.”

And so, with a deft change of tense, the author had leaped over the pain of writing to the future perfect satisfaction of having written.

Some business leaders or software developers are like my friend and do not like to write functional requirements.

Do not like to write may mean:

  • Do not want to take the time
  • Do to want to spend the money
  • Do not think it is necessary
  • Do not know how to write a good functional requirement

Rarely would a business sponsor approve a project without requiring requirements. All too often, however, even with good intentions, the requirements produced look as though the author(s) did not like to write.

The requirements lack fundamental qualities of correctness, completeness, clarity, concision, and consensus (among others).

I don’t like to write, either, if poor requirements result.

My safeguard against poorly written requirements includes using the fundamental Rapid JAD principles:

When practiced routinely, these methods greatly assist my writing process and I produce better requirements. By capturing findings during Rapid JAD sessions, I am more likely to snare the essence of a discussion.  By documenting once, I create a single source of truth accessible to others, and by making these processes visible to all, I rapidly gain and confirm consensus.  Finally, by revising quickly, I am able to refine requirement statements as needed to ensure that they are in good order.

I might not like to write, too, if I did not use Rapid JAD techniques.

But as it is, with Rapid JAD, I love writing (requirements) and I love having written!

Facebooktwittergoogle_plusredditpinterestlinkedinmail