In my ten years of working within the IT industry, managing requirements has never been a clear-cut task, especially when the triple constraints – Scope, Cost and Time – always change due to business conditions. (For more information on the triple constraints, please refer to the latest version of the PMBOK guide.) But suffice it to say, managing requirements is challenging because of their ambiguity, which happens when they have not been communicated clearly to the appropriate stakeholders. To make matters even more challenging, ambiguity further propagates depending on how the various stakeholders interpret those requirements and document them. As this infamous comic cleverly illustrates:

So, how does one effectively manage requirements? In this blog, we will explore four steps to answer this question.
  To understand how we must manage requirements, we must first understand the definition of requirements management.
  Requirements management focuses on two critical aspects:
  1、Understanding the goals of the organization and its customers.
  2、Transforming these goals into potential functions and constraints applicable to the development and evolution of products and services.
  http://www.iibachina.com/thread-2460-1-1.html
  Based on this definition, one can allude that we need “a systematic approach to eliciting, organizing and documenting the requirements of the system, and establishing and maintaining agreement between the customer and the project team on the changing of requirements of the system.” How can we achieve this?
  To demonstrate, let’s look at Step 1, a simple high level process flow for requirements management:

  As you analyze this diagram, you will notice that it does not show what to do when capturing ambiguous requirements and, more importantly, how to convert them to unambiguous requirements.
  An approach that Online Business Systems’ (OBS) Alberta Region Business Analysis practice is attempting to distill amongst its Business Analysts is the OBS Overarching Model (OOM). In Step 2, we embody this model in our psyche every time we engage stakeholders. If we constantly have this model in mind when collecting requirements, it will help to convert many ambiguous requirements to unambiguous requirements.