Requirements are the basis of everything: estimation, development, testing etc. Some people think that requirements-related work is none of the developers' business and should be completely done by the project manager. A project manager may be able to guarantee that requirements are documented before every sprint but may not be able to make sure that all things needed by developers are included in the requirements.

Everyone knows that you'll never reach the destination, if you start in the wrong direction from the very beginning.  So, what would happen if some function was missing or the requirement was been misunderstood by the developer? No matter how wonderful of a job the developer has done, to the client, it means nothing.  Requirement analysis is a very important skill for a good programmer.

How can a developer understand requirements clearly?
First, you need to get to know the exact meaning of each sentence in the specification.  Don't be shy to ask people for help (although obviously first look up any unknown words in the dictionary).  Even if the specification has been written in your native language, it's possible that it is still not understandable. If no one in your team knows the meaning, don't hesitate to ask the person who wrote the specification or the client. There may be slang that we are not familiar with or some typos leading to meaningless sentences. Anyways, make sure you understand it.

Most developers start coding after they finish the first step. However, understanding requirements does not mean only understanding the meaning of every sentence or every word in the specification. The most important thing is that you understand the purpose behind what the client wants.  In this, help the client to make the requirements clearer and more reasonable. Think about the specification deeply and ask yourself some questions like:
• Is there anything mentioned in the specification that conflicts with another one?
• Is there anything missing in the specification (e.g.  Something in the wire-frame that isn’t in the specification)?
• Is there anything that requires more details? Sometimes a simple sentence turns out to be a very big feature. Here’s an example from one of my recent projects: “user can upload  images to his profile”.  
          - Where should the upload link/button be placed?  
          - Are there any restrictions on image size/layout? 
          - How many images user can upload each time? 
          - Any restriction on the total image size or the total count of images? 
          - How should these uploaded images be displayed? 
          - Who has permissions to view these images? 
Anything uncertain will impact the estimation and the scheduled progress.

• Is there anything that seems unreasonable? Assuming you're the end user, what would you prefer? What is more user-friendly? Tell your customer what you think is better and why.
• Is there anything that will cause serious performance issues?
• Is there anything that we're not able to implement according to current technology limitations, or restrictions by third party?

You may think of more questions than those listed above. The purpose of this is to help you find the potential problems.  It's better to foresee the issues before start than to get stuck in the middle of development.

I still don’t understand.  Maybe I should ask the customer…
After you've done the analysis above, you're ready to post questions. There are two things to pay attention when you post your questions:

1. Express yourself clearly.
Make sure that others can understand what you're trying to say.  Here are some tips that may help:
• Point out which specification your question is related to.
• Use screen-shots and images to describe the issue clearly.
• Usually not everyone on the team has technical background, so avoid using too many technical terms.
• Sometimes it's better to just make up some use cases for easier explanation. 
• Being concise is much more important than crafting beautiful sentences. So don't mention anything non-relevant in your question.

2. Give suggestions.
It is much easier for others to answer your questions by answering 'yes' or 'no' or selecting one from several options.  Based on the goal of the specification, list all the viable solutions you think will work and also include the advantages and disadvantages of each suggestion when necessary.

Hm, my customer didn’t give me the answer that I needed…
The last thing is, instead of just sitting there waiting for an answer, notify the people who need to answer your questions.  You may need to repeat this process often until what you want is clarified.  However, be careful not to bother others for something that is extremely tiny or quite obvious. Too much asking can something be as bad as too little.

Li Pingting is a Developer at Ethos Technologies.