Clear, coordinated, requirements are closely correlated with successful project closure. Small teams can experience several obstacles to developing and managing requirements during the initiation phase of a project. For the purposes of this question, assume that the project team is "selling" the work to the stakeholders (because if the project team is employed by or otherwise bound in a long term relationship to the stakeholders, life is easier, and we're trying to examine techniques to overcome the obstacles, not techniques to bypass the obstacles.
- Non Functional requirements are often more difficult to elicit than functional requirements.
- Soft requirements (style, brand, user experience, security, convenience and other qualitative requirements) are more difficult to elicit than hard/quantitative requirements (e.g. "performance" can be measured in milliseconds or megahertz, or transactions/second/etc.)
- Stakeholders probably don't come to the table with a clear understanding of their own requirements.
- Small teams frequently don't have specialized staff who are experienced in eliciting requirements.
So imagine that you're the PM of a small team trying to convince a new customer that you can complete the project. You and the customer have agreed on the functional requirements, but you know that other project teams can fulfill those functional requirements. How do you elicit the soft requirements and convince the customer that you can (over) fulfill those requirements. (Everyone gets "marketing" as the first answer; it is too easy.)
This question is inspired by a comment made by @mark Phillips here