Ambiguous Specifications

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 remain .

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.

This leaves the descriptions of the requirements. Obviously, the less ambiguity they contain, the better, but a poor description cannot do too much damage if you have a properly quantified fit criterion. However, if you are concerned about this issue, then we suggest that you select 50 requirements randomly . Take one of them and ask a panel of stakeholders to give their interpretation of the requirement. If everyone agrees on the meaning of the requirement, then set it aside. If the meaning of the requirement is disputed, then select five more requirements. Repeat this review until either it becomes clear that the specification is acceptable or the collection of selected requirements to test has grown so large (each ambiguity brings in five new ones) that the problem is obvious to all.

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

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 size , there should be someone on staff who is trained in risk assessment.

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 abandoned . In the case of severe impact, it is necessary to determine how you can mitigate that risk.

DeMarco, Tom, and Tim Lister. Waltzing with Bears: Managing Risk on Software Projects . Dorset House, 2003. This book contains strategies for recognizing and monitoring risks. Jones, Capers. Assessment and Control of Software Risks . Prentice Hall, 1994.

In other casesthey have to be assessed on a project-by-project basis the likelihood and the impact are slight enough that it is preferable to wait and see if the risk does, in fact, become a problem. Some risk remains, however, so it pays to have a contingency plan for the possibility of the risk turning into a problem.

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 affecting your project.

As mentioned earlier, this book is not intended to be a treatise on risk, but we do urge you to realistically consider the risks your project is running. If you believe some of the risks might have a significant impact, then you would likely benefit from calling in some risk assessment help. In the meantime, you can identify many of the risks just by looking through the early part of the requirements specification.

Project Drivers

1. The Purpose of the Project. Is the purpose of the product reasonable? Is it something your organization can achieve? Or are you setting out to do something you have never done before, with only hysterical optimism telling you that you can deliver the objective successfully?

2. The Client, the Customer, and Other Stakeholders. Is the client a willing collaborator? Or is he uninterested in the project? Is the customer represented accurately? Are all stakeholders involved and enthusiastic about the project and the product? Hostile or unidentified stakeholders can have a very negative effect on your project. What are the chances that everyone will make the necessary contributions? What risks do you run by not having the cooperation you need?

3. Users of the Product. Are the users properly represented? While user representative panels are useful, experience has shown that they are frequently wrong in their assessment of what the real users want and need. Are the users (or their representatives) capable of telling you the correct requirements? Many project leaders often cite the quality of user contributions to requirements as their most serious and frequently encountered risk.

Many system development efforts result in substantial changes to the users' work and the way that users work. Have you considered the risk that the users will not be able to adapt to the new arrangements? Remember that humans do not like being changed, and your new product is bringing changes to your users' work. Are the users capable of operating the new product? Consider these risks carefully , as the risk of the users not being prepared to change may turn out to be a substantial problem.

Project Constraints

4. Mandated Constraints. Are the constraints reasonable, or do they indicate design solutions with which your organization has no experience? Is the budget reasonable given the effort needed to build the product? Unrealistic schedules and budgets are among the most common risks cited by projects.

6. Relevant Facts and Assumptions. Are the assumptions reasonable? Should you make contingency plans for the eventuality that one or more of the assumptions turns out not to be true? It pays to keep in mind that assumptions are really risks.

Functional Requirements

7.The Scope of the Work. Is the scope of the work correct? Do you run the risk of not including enough work to produce a satisfactory product? If the scope is not large enough, then the resulting product will not do enough for the user. A failure to define the work scope correctly always results in early requests for modifications and enhancements to the product.

8. The Scope of the Product. Does the scope of the work include all the needed functionality, or just the "easy stuff"? Is it feasible within the budget and time available? Having the wrong product scope risks having many change requests after delivery.

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.

Buy on amazon.com >>

Robertson S., Robertson J.

<< Previous page

Table of contents

Next page >>