The Requirements Pit

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away….

Don’t Gather Requirements—Dig for Them

Digging for Requirements

Policy may end up as metadata in the application.

Gathering requirements in this way naturally leads you to a system that is well factored to support metadata.

Work with a User to Think Like a User

Documenting Requirements

Use “use cases”

Overspecifying

Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need.

Seeing Further

Abstractions Live Longer than Details

Just One More Wafer-Thin Mint…

What can we do to prevent requirements from creeping up on us?

The key to managing growth of requirements is to point out each new feature’s impact on the schedule to the project sponsors.

Maintain a Glossary

It’s very hard to succeed on a project where the users and developers refer to the same thing by different names or, even worse, refer to different things by the same name.

Use a Project Glossary

Get the Word Out

Publishing project documents to internal Web sites for easy access by all participants.

Solving Impossible Puzzles

Degrees of Freedom

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution.

Don’t Think Outside the Box—Find the Box

There Must Be an Easier Way!

If you can not find the solution, step back and ask yourself these questions:

Not Until You’re Ready

If you sit down to start typing and there’s some nagging doubt in your mind, heed it.

Listen to Nagging Doubts—Start When You’re Ready

Good Judgment or Procrastination?

Start prototyping. Choose an area that you feel will be difficult and begin producing some kind of proof of concept, and be sure to remember why you’re doing it and that it is a prototype.

The Specification Trap

Writing a specification is quite a responsibility.

You should know when to stop:

Some Things Are Better Done than Described

Circles and Arrows

Don’t Be a Slave to Formal Methods

Formal methods have some serious shortcomings:

Do Methods Pay Off?

Never underestimate the cost of adopting new tools and methods.

Should We Use Formal Methods?

Absolutely but remember that is just one more tool in the toolbox.

Expensive Tools Do Not Produce Better Designs

Based on The Pragmatic Programmer Book by Andy Hunt and Dave Thomas