- An Investment Story
- Investing in Requirements
- Return on Investment
- Investment Risks
- What to Invest In?
- To Invest or Not to Invest
- Investing in Requirements
- Size of Requirements
- The Value of Requirements
- Reusing Requirements
- What Do I Do Right Now?
- What's the Least I Can Get Away With?
- Additional References for Requirements Value
This chapter is from the book
This chapter is from the book
This chapter is from the book
Investment Risks
Any reasonable investment advisor, and most investment advertising, cautions you about risk. The following are some of the risks related to investing in requirements:
- Not knowing the requirements
- Putting too much effort into requirements
- Being too formal with the requirements and the specification
- Being too casual
- Becoming bored with the requirements process
"Our SAP project had built a budget for the development work being done this year for our SAP installation into Dublin, Ireland. We have only had to spend 53% of those dollars. Why? A more thorough job of requirements de velopment was per formed, resulting in the employment of less programming contractors."
—John H. Capron, Worldwide Systems Technology Manager,IBM Enterprise Systems Group
Risk, as we use the word here, is a potential problem. In project management terms, it means you have to be aware of risks, the likelihood of a potential problem becoming an actual problem, and the impact if it does. If the likelihood is slight, then the best course of action may be to proceed, monitor the risk, and act only if the problem manifests itself. On the other hand, if the risk is considerable and the consequences dire, then the obvious action is to implement preventive measures.
DeMarco and Lister [1] define risk as "a weighted pattern of possible outcomes and their associated consequences." The risks that you face in project work fall somewhere between "slight" and "considerable." Let's look at them and consider the appropriate response.
Risk of Not Knowing the Requirements
This risk must always be considered serious, as it is im pos sible to build the right product if requirements are unknown. Note the requirements need to be known. The builders can know them without having them in writing; undocumented requirements are acceptable in some circumstances. However, it is extremely unlikely the builders can know the requirements if they have not studied the work area into which the product is to be deployed.
From our experience, about 60% of software errors are requirements errors. Thus, not knowing the requirements is, by most people's definition, a considerable risk. As with any other risk, you can calculate the impact of poor or missing requirements. If the unknown-requirements risk becomes a problem you attribute the cost of rework, debugging, error correction, complaint handling, lost customers, and delays while the product is made right to lack of awareness of the requirements.
For strategic products, the impact can threaten the health of your organization. If the product is in any way medical, it can threaten the health of your customers. In any event, you need to assess the impact along with the likelihood of the risk manifesting itself as a problem.
Risk of Putting Too Much Effort into Requirements
This one might seem strange coming from people who make their living consulting on requirements projects. However, it has been our experience that some organizations specify requirements that have already been specified in some other form. The object of the requirements activity is to ensure the right product is built. However, it must only specify requirements that are not already known to the builder of the product.
This risk is usually greatest in organizations that have an inflexible development process. Analysts are forced to grind out the requirements specification and perform whatever else is ordained merely to satisfy the process itself. The risk manifests itself as a delay in building the product, as well as in the dissatisfaction of people involved in the project. Further, builders spend extra time wading through extraneous documentation generated by an inflexible development process.
A balance exists between not putting enough effort into the requirements activity, and putting in too much. You have to assess the skills and knowledge of the builders and determine if the requirements analysts are feeding them what they need or more than they need.
Risk of Being Too Formal with the Requirements and the Specification
You do not have to write down all requirements as atomic statements, provided you have some other way of communicating them and provided this other way of communicating serves as a record of the requirements. For example, if you have a set of process models supported by process specifications, a data dictionary, and a data model, then these models may be sufficient specification of the functional part of the product. If the models are rigorous, little is gained by writing out each functional requirement.
Alternatively, you may have fully specified a product use case. This specification includes the preconditions, the exit criterion, a description of the process, and the actors. Provided the use case is relatively simple, this specification alone may suffice as functional requirements.
Please bear in mind neither of the above alternatives specifies the equally important nonfunctional requirements. These are the properties or qualities the product must have. The alternatives mentioned deal only with functional aspects of the product.
Factors that help to decide the necessary degree of requirements formality are:
- Degree of hierarchy and politics
- Fragmentation of knowledge
- Geographical distribution of stakeholders
If you have several levels of management and the requirements must be reviewed at all levels, you need consistent formality. If requirements knowledge about a particular subject is scattered among several people, you need formality; otherwise, you waste a lot of time dealing with inconsistent interpretations. When stakeholders are located in different offices, buildings, cities, or countries, then you need more formality to avoid misinterpretations and wasted time.
Risk of Boredom with the Requirements Process
This investment risk applies to projects in which you determine the requirements by communicating with business users. The business users are giving you their time in the expectation they will eventually get a suitable product. Business users generally feel the time they spend with analysts is time away from their own work. You need to give them something in return for their time, and give it quickly and often, so they do not become bored and discontent with the requirements process.
The boredom risk manifests itself in the behavior of business users participating in the requirements process. They believe they are contributing, but because they lack feedback or because the projected delivery of the product remains so far away, they enter into a robotic-like style of participation. Their answers sound good, but are often intended to get the analysts out of their office.
Practical ways of avoiding the boredom risk are to give feedback on the requirements the user has contributed and to implement early and frequent releases of the product or simulations of the product. Only when the business users (and for that matter the project team) can see the results of their requirements effort do they fully understand the benefits of spending time with the business analysts. By firmly and continuously establishing the requirements-to-product connection in the business persons' minds, you address their reluctance to participate in your project.