How To Shake Up Your Holiday Requirements

Context, Please

Imagine I told you “Go do 5125558679”. I bet you’d be a bit perplexed. On the other hand, if I told you “Please call Tom at 512-555-8679 and give him an update on the project status,” you’d have a decent idea what to do. And, if I handed you a piece of paper with just 5125558679 written on it coupled with the verbal request, that would probably be sufficient to complete the task. Of course, if you needed Tom's number in the future, you might have trouble finding it.


Unfortunately, a lot of SRSs I see look like “5125558679.” And, I’m afraid to admit, some of the SRSs I contribute to make a giant leap forward and looking like “512-555-8679.” They have the critical information people need right now. But, no real context. We’re all moving so fast, that we tend to only have time for the critical.


But, what is the cost of this? Those intimately involved with the project know what to do, but anyone coming in fresh is totally lost. Further, over time, even those intimately involved can forget the meaning. Documents in which a lot of effort was invested become at most marginally useful.


When writing documents, please remember your audience is typically not just the audience you know about now, but also unknown readers in the future. Give them a little context. In fact, I have some I’m working on right now that I realize could use a few sentences that would add a lot of context for that unknown reader…

Productivity Tips

There’s a thread on the Seilevel Message Board, Stupid Analyst Tricks, in which people are sharing nifty little productivity tips. Check it out.

The Seilevel 2007 Holiday Medley

From our Holiday Newsletter:

Back by popular demand, we have new holiday songs! For the 2006 songs, check here holiday songs.

Let it Go
Oh the product release is frightful,
But our status is so delightful,
And since there’s no need for woe,
Let It Go! Let It Go! Let It Go!

It doesn't show signs of breaking,
And we've got no time for taking,
The risks are looking to be low,
Let It Go! Let It Go! Let It Go!

When we finally reach midnight,
We’ll watch as our fancy product goes
And then we will all sit real tight,
To see how our new release glows

Now the rush is slowly dying,
And the team can start good-bying,
And together we sing real slow,
Let It Go! Let It Go! Let It Go!

Do You Hear What I Hear?
Said the user to the BA
Do you see what I see
Over on my screen, BA
Do you see what I see
A task, a task
I must do each day
It’s important to do this way
It’s important to do this way

Said the BA to the developer
Do you hear what I hear
From the SRS, developer
Do you hear what I hear
A doc, a doc
Represents the needs
With a voice as big as the SME
With a voice as big as the SME

Said the developer to the great tester
Do you know what I know
Within your cube walls, great tester
Do you know what I know
A SME, a SME
With requests so bold
Let us show him it works as told
Let us show him it works as told

Said the tester to users everywhere
Listen to what I say
Have some patience, users everywhere
Listen to what I say
The code, the code
Released yet tonight
It will bring you lots of delight
It will bring you lots of delight

The team, the team
Pull together tight
We will bring you products just right

Hark the Herald BAs speak
Hark the herald BAs speak:
“Gathered features for the week!
Please let us keep scope creep mild
We and coders reconciled”

Joyful, the team’s alive
Join the triumph with high fives
Sung to the agile-ist tune
“Features are ready for the war room”
Hark! The herald BAs speak“
Gathered features for the week!”

Requirements Wonderland
Users speak, are you listening,
In their eyes, features glistening
A beautiful sight,
They’re happy tonight.
Walking in requirements wonderland

Gone away is the scope creep,
Here to stay is a new release
Nothing will go wrong,
As we go along,
Walking in requirements wonderland.

On the whiteboard we can build a strawman,
Then pretend that it is set in stone
They'll say: Are you crazy?
We'll say: No man,
But you can do the job
You’re not alone

Later on, we'll conspire,
To not cause a project fire
To face unafraid,
The plans that we've made,
Walking in requirements wonderland.

Deck the Halls
Deck our desks with reams of paper,
Blah la la la la, la la la la.
Requirements out of vapor,
Blah la la la la, la la la la.

See the dull SRS before us
Blah la la la la, la la la la.
No way to tell if the doc is porous
Blah la la la la, la la la la.

Must we all read long lists of text
Blah la la, la la la, la la la.
Might you try some models, they’re best
Fa la la la la, la la la la.

Tools and models make it better
Fa la la la la, la la la la.
Sing we joyous, all together,
Fa la la la la, la la la la!

Projects are Too Big

A big challenge in requirements are today is that projects are often too big.

So my immediate reaction when talking about this with coworkers was to form an image in my head of a little guy (think Ziggy) standing in front of a 3 story wall that’s about 60 feet long. On the wall is a representation of the entire project; it’s covered in diagrams and scratches of text…very “engineering like”. Little Ziggy is looking up at this wall and is completely overwhelmed with where to start.

But in all seriousness, I have seen it time and time again, huge projects with many system integrations and literally hundreds of people involved. Executives want to change the world, and teams of developers, business analysts, testers, business users, etc. set out to do just that. And frankly, none of them seem to deploy on time or budget. I think they believe they can subdivide the project into parts, and have smaller teams own the parts. Unfortunately, this is almost never well managed.

In fact, in another post, I talked about the differences between systems and software projects and that one of the needs was to have someone accountable at the system-level for communications. But I question whether realistically one person can own such a large project and in such a way they can actually understand all of the moving parts.

At the end of the day, the only way you could manage a project is to have the right tools. And it’s not just tools to manage requirements, but tools to manage communications also. A team of 100 people can’t all possibly know what’s going on in all other parts of the project, and so that gets pretty risky. They need to be able to understand dependencies, and flipping through word docs won’t help that. Sorting through massive email threads won’t either. Getting 100 people in one room isn’t realistic. So, the best we’ve come up with so far is some tools to create an environment in which large teams can communicate, review history of communications and filter on what they care about.

The Odd Couple

Remember the play, movie and/or TV show The Odd Couple? The main characters were Felix and Oscar, two recently-divorced men who were sharing an apartment. Their marital status was just about the only thing they had in common. Felix was a neat-freak - everything in its proper place, neat and tidy. Oscar was a slob - a mess and cigar smoke followed him everywhere. But they made their differences work, and those differences showed the audience their friendship and, at the core, their similarities.

Why the reminder about this show? I recently helped facilitate a requirements session in which I was one half of an odd couple. I was Felix - I wanted to know everything about the project before I walked in the door. I wanted to know exactly what the project stakeholders' expectations were. I worried that the session could be a huge mess if we didn't have more details up-front.

My facilitation partner was Oscar (sans cigar smoke). He was full of energy about the project, especially because we didn't have all the answers. To Oscar, we had an opportunity to try new things, to introduce new tools and methods, and to generally have fun with the group. Oscar planned the session, communicated with the stakeholders in advance, and prepared our materials.

On the morning of the session, I was still nervous, and Oscar was still excited. We started the day, and the new methods and tools were working well. The team was coming together, and I was happy to see that my initial worries weren't going to be issues for the work.

We did run into a few bumps during the session, though. Once or twice, the session got a bit too unstructured, and Oscar worried that he'd lost control of the day's activities. He and I discussed the situation during a break, and we decided that I should facilitate for a while. Given our differences, the changes in pace and style were significant. The group reacted differently (more Felix-y, if you will) to my more staid approach to facilitation, and we quickly moved back to a good balance of control and flexibility. At a natural transition point, Oscar picked up the reigns once again, and we kept making progress with the team.

I learned a lot from this experience. First, I saw how a good RE can "go with the flow" in a way that's productive, fun, and allows the group to take the discussion in natural directions. I also saw how a simple change in style can un-stick a group. Whether the transition is from flexible to controlled, or vice versa, the group's reaction was quick and distinct. And I saw the importance of differing styles of requirements practices in action. Either Oscar or I could have held a very useful session with the group on our own. Working together, though, we made the session more productive and more fun for everyone involved.

I'd suggest thinking about this sort of balance any time you lead a requirements session, whether on your own or with a peer. In either case, including some Yin with the Yang, some oil with the water, and some Oscar with the Felix will be a benefit!

Agile Requirements – The use case narrative

Last month I wrote about Agile Requirements and a concept called GRIT or Great Requirements in Total. The idea behind GRIT is that it is important to deliver great requirements models along with great working software. GRIT recognizes that software is a product, not a project, and should be managed as a product over a product lifecycle that will involve multiple projects with many product releases. The requirements models provide stability and continuity across iterations and projects.


Agile development teams commonly rely heavily on face-to-face conversation for communication with customers and between team members. One of the principles behind the Agile Manifesto is that face-to-face conversation is the most effective method of conveying information. This focus on human interaction is one of the things that make agile development an attractive, and generally effective method of delivering working software that actually does what the product users want it to do. It also presents significant challenges as teams try to apply agile principles to the development of larger, more complex software products with teams that may be geographically dispersed across different time zones working on different components that must be integrated to form the completed product. Over a long product life cycle, face-to-face conversation may just not be possible as the people who make up the team, both customers and developers, may have changed.


Great requirements models make it possible for small, agile teams to work independently on different components or releases of a product. The teams can be separated by distance, with little chance for face-to-face communication, and still work effectively on different components of a large, complex product. Or, the teams could be separated by time, working on different releases of the product, possibly separated by years and even working on separate projects.


I recently had an opportunity to observe a team creating a requirements model that I thought showed a real understanding of the challenges of agile development of complex products and how the concept of GRIT can be applied to improve outcomes over the life of the product. The team had worked with user stories on projects in the past but felt they needed a more robust model for the complex product they are working on now. This product is expected to be in use for many years and will almost certainly have multiple upgrades and releases during that time.


The team switched from writing user stories on index cards to writing use case narratives and managing their collection of use case narratives in Excel. A true requirements management tool might be a better choice for long term management but Excel has the advantage of being widely available and pretty easy to use. The use case narratives start out as little more than user stories but they can be progressively elaborated as more details become known and alternate flows are identified. They are still pretty light weight and are easy to refine, rewrite, or refactor. The team is using the collection of use case narratives for backlog management and iteration planning. More detailed modeling and acceptance test planning is done ‘just in time’ when a use case or alternate flow is included in the scope of an iteration.


The plan is for the use case narrative model to be maintained as a long term repository of requirements in the language of the customer. Future project teams and customer representatives will be able to tap into this knowledge base when the time comes to change or upgrade the product. I like this example of GRIT in action.

Using PDAs for Requirements Gathering

I heard a talk at RE07 called Exploring Scenario Forms and Ways of Use to Discover Requirements on Airports that Minimize Environmental Impact by Maiden, N., Ncube, C., Kamali, S., Seyff, N. and Grünbacher, P.

First I want to say that hands down, Neil Maiden gets my vote on best speaker I heard at RE07 – if you get a chanced to hear him, he’s very fun! Anyway, more to the point, at RE06, this same group of people presented a paper on using PDAs for requirements gathering. I posted about that here, including my noted skepticism about the usefulness of PDAs for requirements efforts.
Well, they reported back this year on a project they were doing that used the PDAs. First, I have to say the project was really interesting! They were working with an airport to try to minimize the impact on the environment by reducing the noise and gas emissions. I believe they studied everything from the airplanes on the ramp, to the luggage carousels, to the car traffic around the airport.

They used their PDA tool on this project (though the actual focus of the research was on some visualization techniques). As an example, they would go to an aircraft as it parked at the gate, to talk to the people in context. They recorded the conversations to the PDA and attached them to the appropriate pre-defined event in the PDA. He gave a great example of how handy it was. He was walking through the control tower and saw a small door and asked “What’s in there?” Turns out that inside that room was an actor no one had identified in the project yet. So he could just zip in, have a conversation he recorded on the PDA and zip back out.

In their research, they found that they gathered 8 times more requirements while doing the sessions in context than they did gathering them in workshops. And of course the implied link is the PDA tool lets you do it in context, though arguably there are other tools to facilitate this if not a PDA.

All of that said, I must admit I am less skeptical than I was a year ago that there are such scenarios that such a tool could be useful; though I still think most projects won’t need this. I’d be interested to hear if anyone had success using tablet PCs for this as well.