GuerrillaDomainAnalysis is an approach to capturing requirements and planning frameworks when several of the following forces are present:

* You have lead time in a project (this can happen in multi-disciplinary work).

* You anticipate a large number of changes after initial system delivery because use of the system itself drives new requirements (this is true of most systems, but it is agonizingly true of systems that support scientific research).

* The system users are not the same as the system commissioners.

GuerrillaDomainAnalysis may be applicable in other arenas as well.

The goal is anticipation of needed and possible flexibility, up front.  This requires extremely proactive information gathering.  Interview potential users first separately to avoid GroupThink.  If you interview them in a group, you have less chance of finding the differentiated requirements that may only manifest themselves late.  The is analogous to police detective work where witnesses are always interviewed separately.  Later you can talk to them together about priorities and do reality check on the requirements.  However, in the initial work you are trying to make sure you don't miss anything.

Among all the interviews find the one thing that everyone agrees that the system will not have to support, and then plan for it.  You don't have to tell anyone you are doing this, but it can be a lifesaver.  The logic here is that even if you do not ever implement the feature, having planned for it, you will be able to confront it later.  If everyone agrees that something is not needed, it could be due to an amazing homogeneity of vision or a group blind spot.  Be a good scout, be prepared.

Be sure you understand that analysis is not a commitment to build.  You may do analysis for a very flexible system that may cost too much to build, but having done the head work, you can put it on the shelf and narrow the scope of flexibility as you approach design.  You have gained, however, by considering more flexible approaches than what you eventually settle upon.  Avoid AnalysisParalysis by having fixed deadlines for all these activities.

Be aggressive about requirements gathering.  Talk not only to the users but also the people who use the work of the users.  Live their work.  Do it if possible.  Factor in previous change trends.  Talk to the users about their history.  Find all the ways it has been done.  Do ScenarioPlanning to make sure you have your bases covered.

Understand that Analysis is not really engineering.  It is a micro-science: scientia, knowing.  Engineering asks "how do I solve this problem?"  Science asks "what do we know"  Analysis asks "what do we know and what is the problem?"  Be aggressive.  Make sure you are working on the right problem.  Take nothing at face value.  Read your users.  Think about what motivates them.  Look for the answer behind their answers and check it with them.  Assume that users always know more than you do, and squeeze it out of them.
-- MichaelFeathers