Requirements Anti-Pattern: That Can't Be All They Need

One anti-pattern in requirements gathering that I have seen... a habit of making up for incomplete or erroneous requirements by anticipating more than the user is asking for. It's a different kind of overbuilding.

This seems to be an attempt to account for the fact that the requirements that have been gathered might not be accurate. We might have specified that a user can run something on-demand. Then, we might overbuild by allowing the user to schedule the process to run at a specified time in the future. We might further overbuild by allowing them to specify recurring intervals for the process to run.

Instead of confirming the proper requirement was captured, you build to satisfy the requirement as you think it should have been captured. This is related to goldplating, but is more specifically accepting that your requirements gathering abilities are deficient, and so instead manufacturing requirements to meet your guess at what the requirement should have been.

Waterfall 2006 - International Conference on Sequential Development

I wonder if I can get my company to sponsor a trip to this conference:Waterfall 2006 - International Conference on Sequential Development

Tennis or Bowling?

Some companies, for better or worse, leave the requirements-based testing of their internal-facing software to the end-users.

Unless project management is clear about the responsibilities of the testers, you can run into a "tennis" situation. This situation occurs when the tester believes their goal is to find something wrong with the product. This is attractive to the end-user because it means that as soon as they find something they don't like, they can stop testing until the developer comes back with the problem fixed. After all, testing isn't their job, they have real work to do.

What is needed instead is more like bowling. The tester sets up the pins (test cases), and the developer knocks them down. How pany pins are in a frame, and how many frames are in a game, etc, depends on your development lifecycle.

Developers can sense when they're stuck playing tennis, but they sometimes describe it as shifting requirements. There is a distinction to be made, however. With requirements drift, you're still bowling, but they're moving the pins around on you, or adding pins to the frame.

It is important to define responsibilities at the launch of the project (if not earlier), and to be clear about how the development lifecycle is going to be structured.

Requirements validation anti-pattern

One thing I have seen a lot of is validating requirements with a completed system. This has been sometimes misnamed "User Acceptance Testing".

This typically means that someone shortchanged requirements gathering, by making a guess at what the users need, and having the developers do it.

In its most pathological mode, "User Acceptance Testing" also suggests that the users are doing functional testing as well, and that developers do not need to test their product.

Requirements Uncertainty Anti-Pattern

One strategy I have seen for 'managing' requirements uncertainty is to hire permanent or contract developers so that they are available to respond to requirements changes. I call this the 'embrace and extend' anti-pattern. Instead of minimizing the chances of this risk materializing, or limiting the effect of this risk in the event it does materialize, this approach accepts the maximum penalty for risk materialization from the outset, and actually encourages requirements changes. Why do managers engage in this anti-pattern? What are some alternatives?

"We're not a software shop."

Working as a developer in IT organizations, I hear this objection "We're not a software shop" come up a lot when people suggest things like using revision control, or writing down requirements, or formalizing change management.

Saying that because we are not a software company, we can do a good job of developing software without employing the techniques of professional software developers is like saying that because I am not an athlete, I can win a triathlon without training.

Contentious Issues Aren't.

Often we will waste tremendous amounts of time debating a choice between alternatives. Where to have lunch, how to implement a feature, how to model some data, blah, blah, blah, ad nauseum.

Funny thing is, we usually don't get into debates like this unless there are compelling arguments on both sides of the issue. The more heated the arguments, the more likely it is that either alternative provides near equal utility.

In these cases, you might as well flip a coin. Make an arbitrary decision; move on.

Similary, don't bother defending the alternative you chose under such circumstances. You made a choice because you had to, not because you had a clear superior alternative. If you could have defended your alternative, the decision wouldn't have been arbitrary.

Boing Boing: FIling system optimizes documents by use-frequency

This rather different approach to filing treats the file cabinet as a "stack". When you file something, you put it at the front of the shelf. When you pull it to work with it, you return it to the front of the shelf when you're done. This results in the files naturally moving to the back of the shelf if you're not working with them, and staying near the front of the shelf if you refer to them frequently.
On the one hand, intriguing. On the other hand, sounds an awful lot like the pile of folders I had on my desk before I learned to file things away.

Two great online resources

CreatingMinds.org is a collection of creativity methods for generating and selecting ideas.

ChangingMinds.org is a collection of persuasion methods.

Both of these sites are maintained by David Straker, author of the cult classic Rapid Problem Solving with Post-It Notes

i d e a * i d e a - How to Bubble Map - drawing your To Do the stress-free way -

Great idea for visualizing your to-do list in terms of how much mindshare each item has. Could also be adapted for how Important or Urgent.