With perseverance and the cooperation of the various stakeholders, you can successfully implement improved requirements development and management practices in your organization. You should select practices that will solve or prevent specific requirements-related problems that your projects experience. After you’ve identified the most pressing issues you’re going to address, it’s important to determine the root causes that contribute to each observed problem. Effective solutions confront root causes, not just superficially observed symptoms.
This appendix lists many symptoms of requirements-related problems that you might encounter. The symptoms are accompanied by related possible root causes and suggestions for dealing with each problem. Of course, these aren’t the only possible problems, so extend this table with your own experiences as you encounter—and handle—symptoms that aren’t listed here. Sometimes observed symptoms are themselves root causes of other problems. For instance, the process symptom “People performing the BA role don’t know how to do it well” is a root cause of numerous elicitation symptoms you might observe. These things chain together; not all of the possible links are shown here.
Unfortunately, there’s no guarantee that a proposed solution will cure your specific symptom, especially if the underlying problems are political or cultural in nature or if the root causes lie outside the development team’s sphere of control. As we’ve cautioned before, none of these solutions will work if you’re dealing with unreasonable people.
Problems are conditions that lead to a negative impact on your project. Signs that indicate that your projects might be suffering from requirements-related problems include:
A product that doesn’t satisfy user needs or meet user expectations.
A product that requires corrections and updates immediately following release.
A delivered solution that doesn’t help the organization achieve its business objectives.
Project schedule and budget overruns.
Team member frustration, loss of morale, loss of motivation, and staff turnover.
Extensive rework during development of the solution.
A missed market window or delayed business benefit.
Loss of market share or revenue.
Product returns, market rejection of the product, and poor reviews.
Any attempt to change the way people work or the way an organization operates might encounter resistance. As you identify corrective actions that could address the root causes of your requirements problems, also think about the obstacles that might make it difficult to implement those actions, and possible ways to get around those obstacles. Common barriers to implementing changes in requirements practices include:
Lack of recognition of the problems that current requirements practices cause.
Lack of time—everyone is already too busy.
Market or management pressure to deliver quickly.
Lack of management commitment to investing in a requirements engineering process.
Skepticism about the value of requirements engineering.
Reluctance to follow a new or more structured requirements or software development process.
Politics and entrenched corporate culture.
Conflicts between stakeholders.
Inadequately trained and skilled team members.
Unclear project roles and responsibilities.
Lack of ownership and accountability for requirements activities.
Notice that these are people-oriented and communication-oriented issues, not technical impediments. There are no easy ways to overcome most of these barriers, but the first step is to recognize them.
To use this section, identify symptoms that suggest that requirements activities aren’t going as well as you’d like on your project. Then search the “Symptoms” columns in the tables for something that resembles your observation. Alternatively, scan through the “Symptoms” columns for conditions that describe your project or organization. Next, study the “Possible root causes” column for each symptom to see which factors might be contributing to the problem in your environment. Finally, select practices and approaches from the “Possible solutions” column that you think would effectively address those root causes, thereby—if all goes well—resolving the problem.
The symptoms described in this section suggest that your requirements development and management processes are in need of a tune-up.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
|
|
Certain problems with the products you build indicate that improved requirements practices might be advisable.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
The symptoms listed in this section suggest that the ways in which requirements and project planning intertwine are not being handled optimally.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Many problems, including those in the following table, arise because of ineffective communication among project stakeholders.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
|
|
|
|
|
|
Many symptoms suggest that those team members who are engaged in requirements elicitation are not performing as well as they could be.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The symptoms described in the following table indicate that more effective requirements analysis is advisable.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
The symptoms in the following table indicate shortcomings in the way that requirements are being specified for the project.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
| |
|
|
|
|
|
|
It’s difficult to know for sure if the requirements you’ve developed will in fact achieve the intended business objectives. The symptoms in this section are indicative of requirements validation shortcomings.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
One sign that requirements are not being managed well is that not all of the intended requirements are implemented.
Symptoms | Possible root causes | Possible solutions |
|
|
|
There are many indicators that a software project is not handling change requests well, several of which are itemized in the following table.
Symptoms | Possible root causes | Possible solutions |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|