1. 3
  1.  

  2. 2

    I agree with the article that having something tangible to poke before further discussion of requirements is a good idea.

    I would advise to go even further when possible: if software is supposed to be used in an intensive way (for example, when automating some workflow) — letting programmers sit together with the users for a few hours as they use software together may pay off for the same reason of creating a common reference as discussed in the article.