Within a discussion on the ArgonDigital message board about the characteristics of a good requirement, Elaine and Gescober discussed whether a requirement must be feasible in order to be a good requirement.
While initially it looked like they had opposite opinions–Elaine: No, Gescober: Yes– they’ve seem to have come to some meaningful points of agreement:
- A requirement must be feasible to build a project.
- Explicit discussion and resolution of requirements which are not feasible allows you to keep expectations in synch with reality. If a requirement is not feasible, you must decide whether to alter the vision and expectations of the project to exclude it, or halt the project because it cannot sufficiently meet expectations.
It may seem like an obvious conclusion, yet how many times have you seen it happen:
- Requirements left out because they are infeasible, resulting in disappointed users –“Why didn’t you tell me I couldn’t have what I wanted?”
- Requirements sent to development which are infeasible, putting the development team in a no-win situation–“Why did you commit me to building what I know can’t be built with the constraints I have?”
We must be candid with our users; if they want something they can’t have (for what they are willing to pay), we must tell them.
