The risk is greatest at several points:

1. Overlooking a crucial requirement

This one the greatest risk in RE. If you overlook an important user class, you'll probably have to spend much more time to add in it or even redo the whole project!

How to avoid this risk?

• always keep in mind to figure out what the important parts are from the customer's requirement.
• keep the scalability of your software.

2. Inadequate customer representation

Which means there are many designers are so confident about their skills that they think they have understand exactly what customers need and doesn't spend enough time negotiating with their customers.

How to avoid this risk?

Never be arrogant that you have understand all of the requirements your customers need without keep in touch with them.You have to spend more time on negotiating with your customers.

Customers only discover if we had the right idea when they attempt to use our software.

3. Modeling only functional requirements

?

4. Not inspecting requirements

The cost to remove defects in requirements increases geometrically with time.

Inspecting your requirements model is the most effective way to identify ambiguities, unstated assumptions, conflicting requirements, and other defects at the earliest possible point.

Every requirement may have some defect, so don't be too confident to ignore inspecting your requirements.

How to avoid this risk?

• be patient in finding defects in your requirements.
• You can find a team to do this work for you, if you want.

5. Attempt to perfect requirements before beginning construction

The time when we could know everything we needed to know before starting software construction is long past.

It's safer to assume that our requiremens are going to change than that they won't.

How to avoid this risk?

• Do the best job you can early to get a good set of requirements, but don't be discouraged if everything isn't absolutely certain. Identify those ares of uncertainty and move on, ensuring that someone is responsible for closing those gaps in your knowledge before construction is complete.
• Track the uncertain requirements carefully as your project proceeds.

6. Representing requirements in the form of designs

?

Reference:

[November/December 2001] "The Top Risks of Requirements Engineering", Brian Lawrence, Karl Wiegers, and Christof Ebert   IEEE SOFTWARE