ArgonDigital - enterprise automation experts

Share This Post

All Thumbs: Use Observation Elicitation to help define your unknown software requirements

Several years ago when I bought my first 4WD vehicle, I watched a video on off-road driving. One of the bits of advice in the video was to always keep your thumbs on the outside of the steering wheel to avoid having your thumb broken if the wheel should suddenly jerk.

“But I always do that anyway,” I thought, and then I wondered why.

Then I remembered watching my dad drive, and watching my dad teach my older sister to drive. (He was gone by the time I learned how to drive.) He NEVER drove with his thumbs inside the steering wheel.

And then I knew why, because my grandpa had raced stock cars on the dirt tracks of Oklahoma. And he taught my dad to drive. It’s a long way from rural race tracks of the 1930s to the logging roads in the Pacific Northwest where I put my driving skills to the test. It’s very different, and yet the same.

Every day, we do things instinctively, like driving with our thumbs outside the wheel, and never think about why.

When our project stakeholders are telling us about their business needs and problems, how many meetings and workshops do we sit through without ever learning about activities that are so ingrained and habitual that they are never thought of?

Job shadowing and the Observation Elicitation technique is often not an option that is given to business analysts to gather requirements, but it is one of my favorite techniques. I can learn more by spending two hours with a real person doing a real job than in a month of reviewing documentation.

Why don’t we do it more often? Is it considered intrusive? A waste of the system user’s time to entertain a business analyst in his cubicle for half a day? Or is it perhaps that we don’t like to be the beginner with a notebook in hand, innocently asking ‘”why?” Or is it just that a dozen other consultants and specialists have been there before us and sat in the cubicle already, so that if we ask for the same privilege, we’re likely to get a dry-erase marker chucked at our unsuspecting heads?

I was in a meeting the other day with a team of people who are committed to designing a new sales tool. Someone pulled up one of the existing sales tools and displayed the screen on the overhead projector. Turns out, no one else in the room had even seen it before.

“This is how we do our sales process today,” the presenter said. A dozen questions and realizations all came to light at once. It would have been so much easier to go through a few different Observation sessions at the beginning of the project to elicit needed requirements. Now there is a lot of catching up to do.

Sometimes, we all just need to spend more time in cubicles to uncover why things are done the way they are; especially if, for the user, they are done instinctively.

All Thumbs: Use Observation Elicitation to help define your unknown software requirements

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage