So, is using Cucumber to (near)exhaustively define complex interactions of requirements by example an abuse of the tool?
Is it appropriate use of Cucumber (or any other specification by example tool) for documenting the complex interactions of rules? Global rules in written requirements can leave ambiguities about how they interact with each other. Thus it would be nice to use concrete examples to document this behaviour. And it is important that the client and the human readable nature of Gherkin is appealing. However there is a guideline:
In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together. Dan North
Whereas for any rule interaction there are easily dozens of meaningfully interesting cases to document. Then for any feature you either end up with dozens of scenarios or thinly slicing your features until absurdity until they are no longer recognisable by the client (eg "that's all part of the 'auto-complete & save' button"). It also is not part not an exploratory process of BDD, but documenting rulings from signed-off requirements.
I work at a consulting company that provides customised solutions for configuration management of relatively complex things like industrial trucks where there are lots of options and the rules and dependencies between options are complex. To make matters worse, there are business rules around auto-fulfilling dependencies if the user hasn't explicitly (eg if you don't specify an engine we will select one for you based on your current vehicle tonnage ), and the rules around tie-breaking between which option can be extensive (such as one of the types of options have 7 layers of tie-breakers).
These things are hard to iron out in requirements using general rules, and are huge source of bugs. There are frequently disputes (because rework involves additional billing as opposed to being covered by the maintenance contract) with the client whether something is truly a bug or do they have a change in workflow/business rules/down stream systems that is a change to the system.
PS - using a different technology (eg rule engine, Prolog) is not acceptable because it would effect the maintenance contract. It must be a pure Java solution.
PPS - we are not agile, we are waterfall so this isn't exploratory, it's part of a semi-official post-process akin to NAFTA's "Memorandum of Understanding"
PPPS - I looked at whether this question is appropriate to ask here and it feels like it falls under "software development methods and practices" and the other Cucumber questions