Pitfalls
We've captured a lot of experience and lessons learned in this chapter. Here are some stumbling blocks you may run into and suggestions for how to deal with them:
-
It's very difficult to find one person who has the qualities of a domain or an SME and is a trained requirements engineer. Often it's easier to place someone with one of these credentials in the role of the requirements engineer. My experience is that it's worth the extra effort and cost to find that one person who has both qualities. The reason is that the domain expert who is also a trained requirements engineer will provide the project invaluable advice concerning the real requirements. If you can't find one person with both skills, my suggestion is to train someone who is a domain expert in requirements engineering. This training will help a domain expert balance her preconceived ideas concerning the solutions with the concept of eliciting the real requirements and being sensitive to implementation issues.
-
Customers will try to put much of the burden for defining requirements on developers. "You tell me; you're the expert," they'll say! Not really. Developers may be trained and proficient in developing systems, but they are not the ones who should decide on real customer needs and expectations. As I've emphasized, it requires a joint effort to define the real requirements. As noted earlier, it is important to train requirements engineers and developers not to make assumptions, not to make requirements decisions, and not to gold plate. You'll find that this investment in training and discipline is valuable.
-
Project start-up situations are often hectic. It's difficult to pay attention to all of the tasks that need to be addressed. This is certainly true with respect to initiating and installing effective requirements practices. Consider utilizing an internal or external expert to assist with needed activities.
-
Don't use "smallness" as an excuse for not taking advantage of the practices, recommendations, and suggestions provided in this book. These are proven practices—on small projects and on larger ones. Tailor your approach based on common sense. Make good use of the underlying ideas and concepts.