Choosing the Best Trawling Technique

We continue to be more and more ambitious in terms of the size, complexity, fragmentation, and level of human involvement in the products that we build. In similar fashion, the trawling techniques we use continue to develop so that they keep pace with our ambition. With this explosion in the number of techniques available comes a question: Which technique is the best choice in which set of circumstances? There is no simple answer to this question because the choice of technique is driven by the characteristics of the knowledge source, and in most cases that means the characteristics of individual people. As a consequence, a competent requirements analyst needs to be able to use different techniques, and sometimes use techniques in combination.

A lot of this knowledge can come only with experience. Nevertheless, Table 5.1 shows the relative strengths of different trawling techniques.

Table 5.1. The Relative Usefulness of Trawling Techniques for Rabbit, Horse, and Elephant Projects

Trawling Techniques	Strengths	Rabbit	Horse	Elephant
Business events	Partitions the work according to external demands	***	***	***
Current situation modeling	Examines the legacy system for reusable requirements	*	**	***
Apprenticing	Spends time working with an expert	*	**	***
Structures and patterns	Identifies reusable requirements	*	**	**
Interviewing	Can focus on detailed issues	***	***	***
Essence	Finds the real problem	***	***	***
Business use case workshops	Focuses the relevant stakeholders on the best response to the business event	**	***	***
Creativity workshops	Brings the team together to discover innovative requirements	***	***	**
Brainstorming	Facilitates creativity and invention	***	***	***
Personas	Uses a composite virtual character to represent the user/customer	*	**	***
Mind mapping	An effective planning/note-taking technique	***	***	***
Wikis	Uses online forums to allow all stakeholders to contribute	**	***	***
Scenarios (Chapter 6)	Shows the functionality of a use case	***	***	***
Low-Fidelity prototypes (Chapter 12)	Discovers undreamed-of requirements	***	***	**
high-fidelity prototypes (Chapter 12)	Discovers usability requirements	***	**	**
Document archeology	Uses evidence from existing documents and files	*	**	***

Table 5.1 indicates the relative usefulness of techniques depending on your agility ambitions. However, other factors can come into play. The availability of stakeholders to participate in the requirements process is a significant factor in determining how you set about gathering requirements. When stakeholders cannot (or will not) make themselves available, getting their input using a wiki is probably the best technique to use. If that does not work out, then using a persona is the best approach. By contrast, if your stakeholders are willing to participate, business use case workshops and apprenticing are effective.

We also refer you to the owls in the margins, which indicate when particular techniques are most effective.

Lastly, use techniques you and your stakeholders are comfortable with. It is a good idea to invest some time in learning new techniques because they encourage you to question the way that you do things and make you more aware of the sociotechnical nature of requirements work. The best results come when you and the people you are dealing with feel at ease with the way you are gathering requirements. If a technique is not working for you, then try a different one.