Before the project
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"
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:
- Is there an easier way?
- Are you trying to solve the right problem, or have you been distracted by a peripheral technicality?
- Why is this thing a problem?
- What is it that's making it so hard to solve?
- Does it have to be done this way?
- Does it have to be done at all?
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:
- Specification will never capture every detail of a system or its requirement.
- The expressive power of language itself might not be enough to describe a specification
- A design that leaves the coder no room for interpretation robs the programming effort of any skill and art.
Some Things Are Better Done than Described
Circles and Arrows #
Don't Be a Slave to Formal Methods
Formal methods have some serious shortcomings:
- Diagrams are meaningless to the end users, show the user a prototype and let them play with it.
- Formal methods seem to encourage specialization. It may not be possible to have an in-depth grasp of every aspect of a system.
- We like to write adaptable, dynamic systems, using metadata to allow us to change the character of applications at runtime, but most current formal methods don't allow it.
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