FAQ (Continued)

Q. My users don't know what they want. How can I get them to write requirements?

A. Hopefully they do have some clue about their needs, or else they wouldn't be talking to you at all. You need to work with them—learn their language, understand their jobs a bit—and help them express their needs more clearly. It's a bit like the classic stage technique of method acting—you might have to live the role to portray it correctly. Same for requirements: Put yourself in their shoes and help them express their needs clearly. Make sure they understand what you are saying and get them to sign off.

Q. How can I start building if the requirements keep changing?

A. This is probably the most commonly reported problem with requirements. In many cases, it arises from the requirements not being well-formed in the first place. Helping the users understand the fundamental business needs, and then helping express those in clear, reliable terms will greatly reduce the amount of change requests. You can help users understand what they are asking for with prototypes.

However, requirements change to reflect changing business conditions. Requirements tools can help here, because the best reaction to a change request is a statement of how much the change will cost. A tool will let you rapidly demonstrate the impact of the proposed changes. Many change requests simply vanish when met with a justified statement of cost. Flexible development methods help handle those that don't.

Q. My developers don't have time to read requirements documents.

A. So they have months to make changes instead? Requirements documents don't have to be long and dull, unless you are building battle ships or space probes. A well-written requirements statement should be readily accessible to all its users. Part of this is a clear, functional structure. This can help developers navigate to the parts they need to work on. A tool can help here as well—good filtering and sorting functions will enable the engineering team not just to find the relevant requirements, but to mark them as completed, too.

Q. Our company thinks that Microsoft Word is a requirements tool. Am I a lost cause?

A. Not at all—all the requirements tools feature at least some level of interoperation with Word. Telelogic DOORSrequireIT lets users work directly in Word documents. The others all feature import from Word into structured environments.

Q. What do design techniques such as abstraction, encapsulation, and decomposition really buy you?

A. The truth is that we could probably design and build a software application that will satisfy today's requirements (a static system) without exploiting sound design principles. In reality, requirements for software systems evolve over time, and this evolution requires a software system that is adaptable. Sound design techniques enable the flexibility to accommodate the future.

Q. What is the best way to learn software design patterns?

A. If a software designer thoroughly understands and consistently practices the fundamentals (abstraction, encapsulation, minimal dependencies, and so on), design patterns will come naturally. This means that, using the fundamentals, you will probably be surprised to find that your designs employ patterns even though you might not have studied them. Learning by studying patterns and then retrofitting a design to use specific patterns is not the right approach. For concrete examples of patterns that evolve from sound design principles, see "The Philosophy of Interface Driven Design" (Java Pro, 2003).