First draft requirements: lessons learned

I recently talked to a friend of mine that had just terminated a preliminary collection of requirements for a couple of new customers; I found his insights very interesting for a bunch of reasons, and I'd like to report some lessons he learned and was so kind to share. Having seen the result of his efforts I'd like to add a couple of thoughts of my own.

• Having just a person conducting the interviews and another one working on the resulting minutes is not a good idea (we're not talking about polishing them up), as it is very time consuming. Better to spread the work among two persons and interact frequently between sessions: even if it might seem more expensive, as it doubles the resources involved, it greatly reduces further analysis and review time and leads to better results (likewise pair programming). This practice also reduces bottlenecks.
  
• A versioning system is very useful. Use it.
• Time spent on "aesthetics", like formatting, logos and such, would be better spent at the pub. Ops, I mean concentrating on the core stuff. A good look should not be important to you. If you really need it (you normally do when you approach a new prospective customer) leave it for someone else when the process is (almost) terminated. Better yet, separate presentation from content.
  
• Don't forget nonfunctional requirements. I am always astonished when I see that nobody cares (or remembers) about security, scalability, reliability, configurability, performance, and so on. I can understand a customer might not think of maintenability at first, but how is it possibile that nobody ever says things like "the system should support no less than 2000 concurrent users" or "the system should adapt to many different situations"?
• Inspect and adapt. Rinse and repeat.
  

Note that the purpose of these interviews was the production of a first draft for a possible collaboration, not working software; nevertheless the same rules hold true also in production time.