Must a Requirement be Feasible?

ArgonDigital - enterprise automation experts

Share This Post

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.

More To Explore

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage