The specification should, as far as is practical, be free of ambiguity. You should not have used any pronouns and should be wary of unqualified adjectives and adverbsall of these introduce ambiguity. Do not use the word "should" when writing your requirements; it infers that the requirement is optional. But even if you follow these guidelines, some problems may
The fit criteria are devices to quantify each of the requirements, and thus make them unambiguous. We describe fit criteria in Chapter 9, explaining how they make each requirement both measurable and testable. If you have correctly applied fit criteria, then the requirements in your specification will be unambiguous.
If the problem is bad, then consider rewriting the specification using a qualified technical writer.
The terms used in the requirements must be those defined in the Naming Conventions and Definitions section of the specification. If every word has an agreed-upon definition and you have used the terms consistently, then the meanings throughout the specification must be consistent and unambiguous.
Risk analysis is not directly connected with requirements; rather, it is a project issue. However, at this stage of the requirements process you have a complete specification of a product that you intend to build. You have invested a certain amount of time deriving this specification, , and you are about to invest even more time in building the product. Now seems like a good time to pause for a moment and consider the risks involved in proceeding.
You, as the requirements analyst, do not have to handle the risk analysis by yourself. If your organization is of a reasonable
Risk analysis identifies the risks the project faces along with the probability of a risk manifesting itself as a problem. In some cases, the impact caused by the risk becoming an actual problem is so severe it forces you to take preventive action. In other cases, the impact is extreme to the point it is a "showstopper"the entire project must be
In other casesthey have to be assessed on a project-by-project basis the
Quite a lot of help is available for identifying risks. Several books have been published that provide checklists of risks. In his book, Capers Jones gives the percentage of projects that have suffered from each of the risks he identifies. This data can be used to help you assess the probability of the risk
As mentioned earlier, this book is not intended to be a treatise on risk, but we do urge you to
Other commonly cited risks include creeping user requirements and incomplete requirements specifications. Risk analysis does not make all of these risks disappear, but it does mean that you and management become aware of problems that might arise and can make appropriate plans for monitoring and addressing them.