Large IT-implementing projects are complex and it is very difficult to control everything in detail. However, you need to reality checks of your solution at regular intervalls with real customer interactions.

For example, when:

A man walks in to the police station and report that somebody has stolen his bike and the question is now if the police have the bike or if he should contact his insurance company.
A woman walks in to a store and would like to buy a mobile phone with a subscription, but keep existing phone number from another operator.
A divorced man would like to open two savings account for his and his former US-born wife's children. He also would like to open a debit-account for himself.
A woman on holiday visits a doctor for an illness and he need to retrieve her previous medical record for the last year in order to make a proper diagnosis.
A house-owner would like to buy electricity from another electrical company and call the sales representative for the new vendor.

These businees events, triggers, business use-cases or what you call them are very important for your customer. If you fail, you seldon get another chance to get a new businees opportunity with this customer.

A common thing in all these events are that they are little more complex and precise than average user stories and that they often involve several parties. They are also more or less very frequent and there is a need for exception-handling when, not if, something goes wrong. If not properly done, there will be a lot of extra manual work for the business.

The reality is more complex than a single requirement. Therefore we need to develop business scenarios that imitates the real world in order to verify the both proposed solution and the implementation

Disruptive architecture