Article – How to Translate “Customer Speak” into Technical Requirements



I frequently employ an exercise when teaching my courses; I ask the audience members to think for one moment of their idea of a "dream home". I ask them whether they thought about this before and the majority of them agree that yes, indeed over the course of their lives they have given this topic a lot of thought and can envision this building pretty well.

Then I tell them that they now have to sit down with me - and I am willing to invest as much time as needed - and describe the house to me in detail, down to the type of flooring in the kitchen and living room, colour of the walls in the master bedroom including the exact shade, specific type and model of faucets in the bathrooms, molding in the dining room area, etc., etc., etc. The goal of this exercise is that at the end of it I should have a detailed blueprint of the building and the bill of materials including product SKUs I can go to, say, Home Depot with and purchase all the necessary supplies.

After a couple of minutes someone in the room exclaims,

“But that is impossible! How can you expect us to know all the little details about the house?”

Why am I telling this story? The reason is that thinking that one can easily come up with a complete list of detailed requirements at the beginning of the project is a self-deception. Requirements elicitation is a long and at times painful process of probing, asking questions analyzing the preliminary results, coming up with more questions and investigating again.

Furthermore, once the technical experts sit down to have any kind of requirements elicitation interaction with customers or users, they (the users) do not necessarily provide the analysts with a structured model of requirements that follows a predefined taxonomy. In other words, the customers rarely start these conversations by saying, “I will cover all of the high-level business requirements first, followed by product features. And at the very end I will provide you with all the functions and attributes of the product".

here is an example from the world of engineering; a conversation between a representative of the marketing team and the design engineer.


"The current corkscrew bottle opener is inadequate for several reasons. Firstly, the customers want a bottle opener that would fit the bottles with square bottle necks. Also it has been reported that the screw itself is a bit wobbly which frequently leads to the destruction of the cork. Another complaint that we had is that the device is too heavy and too big. Can you see if you can decrease the weight and the size of the bottle opener? And by the way, the new device should still conform to our corporate branding standards"


What kind of requirements can we find here? According to the marketing manager the improved version of the corkscrew bottle opener should: fit square bottles, be more stable and still conform to the corporate branding standards, presumably color and shape. There was also a request to decrease the size and the weight of the opener. Let us see if we can record all of these features in a proper – functions (FCT) and attributes (ATT) - project scope management format:


FCT 1.1 - The bottle opener shall fit square as well as round bottle necks

FCT 1.2 - The screw shall deviate by no more than 1/16 of an inch

ATT 1.3 - The bottle opener shall weigh no more than 100 grams

ATT 1.4 - The bottle opener shall fit into a 5X3 inch box

ATT 1.5 - The bottle opener shall conform to ABC Ltd. corporate branding standards

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @

Jamal is an author of three very popular books: 

  1. Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management 
  2. Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects
  3. Project Portfolio Management in Theory and Practice: Thirty Case Studies from around the World