How can small teams elicit high quality soft Non Functional Requirements?

Question

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.

1. Non Functional requirements are often more difficult to elicit than functional requirements.
2. 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.)
3. Stakeholders probably don't come to the table with a clear understanding of their own requirements.
4. 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

Answer 1

The short answer for me is to always have user stories. I come at this with a software dev background, many Product Managers don't have a background in development and cannot think in units of dev work. However, they can work with us on defining who are the end users, and what will they be doing with the end product. Once we can come up with a list of likely users we can flesh out the types of interactions these "users" will be having with the product. Each "user" has a role to play, and thus has a different set of features/functionality that they require. The hard part then is to find the overlap among these "users" and to create hard requirements from that. There will be many soft requirements though that do not fit into definable work units and can be used then as guidelines as to the feel of the product. These soft requirements have to constantly be updated as milestones are hit and those whose buy-in you are seeking see more of the product they can relate to.

Key advantage of this for me has been in getting testable scenarios. The more we can describe in human ("soft") terms the nature of the users interaction with the product the easier it is to come up with a good list of positive and negative test cases.

Having an understanding of the human interaction and a good story for how the product will be tested along they way has always been key to getting buy-in from outside the dev/engineering department.

Answer 2

There is no formula to eliciting and convincing a customer that you can meet their soft requirements. It comes down to relationships and personalities. Some people "click" with each other, others don't.

It can be frustrating, particularly for a small, hungry team, to think that there are some jobs they won't get because of the soft side. But the alternative is spending time and money doing work for free, trying to "help" the customer uncover items which are intangible. It might seem like the customer is getting a good deal since you are doing strategic consulting for them at no cost. But if the customer hasn't asked for it, it is likely that they don't see value in and therefore don't see/understand the value of what you are doing.

There are people who appreciate the soft side that you bring to the table. There are people who "get" you and your team and with whom the team will click. Spend your time finding those customers, rather than trying to convince those that don't click of your value.