Use case: View order processing claendar (i.e., what are my cut-off times for order processing)
1. Use chooses to view the order processing calendar
2. System displays the order processing cut-off start time and end times.
BR: cut-off start and end time is based on either historical actuals (i.e., what were the official times) or based on a future schedules start and end time.

Should this be a BR? What we are trying to say is, that in another “configuration” use case, we can potentially change the cut-off start and end times, which should be reflected correctly when I execute the view order processing calendar.

So bottomline, is I don’t know whether to write this as a rule or just say the system will lookup this information as part of the flow.

Any thoughts?
thank you

1. Accept claim use case
Flow:
1.1 timestamp the claim (once received)
1.2 Validate the calim (this would involve, structural validations – e.g., NCPDP trxn, format validations – required vs optional, numeric vs alpha, etc, content – if the member’s insurance company is “X” and the date of claim is before “Y” then associate claim to insurance company “Z”, etc)
1.3 Based on validation determine whether to reject or continue claim processing.

This is a simple 3 step use case it seems. But, 1.2 has tons of validation rules falling under structure (purely a technical transaction concern), format, content. How do you propose these rules are documented? I mean there can be 100s of rules. For example,
For the Rx number there could be rules like, Rx number must be numeric. Rx number should have 10 digits.

How about if there was a requirement that said, if Rx number starts with “1″ this claim is a worker’s comp claim.
etc…

Bottomline…how would someone document this rules (stuctural, format, content – business and technical) be documented?

A sales commission might be set at 25% of the revenue from a sale. There is no reason why a programmer should be required to change the percentage involved. That percentage is a business rule. The computation of the revenue from a sale would likewise be a business rule.

What is required is the ability to use the specified percentage from the business rule in the calculation of the sales commission.

Signals travel around a circuit. The signal can vary, but the circuit is stable. The signal is the business rule. The circuit is the use of the signal in the calculation.

The circuit is the carrier. The signal is the carried. Requirements define the carrier or infrastructure. A business rule defines the carried or content.

The circuit or carrier must be built, hence a requirement. The requirements need not change when the carried varies.

Thanks again for starting a great discussion. It probably makes sense to move additional conversation to the latest article.

That is definitely a policy (or regulation) being enforced. Many people who are qualified to do the inspection could, but the pilot (of that flight) is the one who is required.

Thanks very much for reading and commenting. I especially appreciate the insight you’ve put into this discussion.

When I describe rules as being “not requirements” I am not saying that they are not required, but rather that they are not the necessary components of an approach to achieving a value-based goal. Rather, they represent constraints on how that goal is to be achieved for a given company.

Those constraints may be external regulations or internal policies that the company has chosen to adopt, enforce, or extend. They certainly represent criteria by which the success of the software will be evaluated.

There is value in making the distinction, although it is more practical than semantic. Why separate rules from requirements? I’m going to switch gears and write that as a blog post right now. I’ll add another comment with a link to it.

While I value the distinction you are seeking to make, I think you’ve got it wrong. Sorry!

Certainly, business rules are not user interactions or system behaviors, so we don’t want their principal residence to be within use cases. And there may well be benefits to a system’s stakeholders from implementing business rules in such a way that they are more readily altered (which is a non-functional requirement that comes at a cost, of course, so we had better strive for net benefits). This should not force us to conclude that business rules are not requirements, however.

In any event, it seems to me that there are other places that business rules may lurk within use cases. First of all, the goal of the use case may itself be compliance with business rules. To take your FAA inspection example: “…before every flight” is explicitly “corporate policy”. That the airline chooses to enforce and monitor this policy is implicitly corporate policy. That the airline chooses to do no more than enforce and monitor compliance with FAA guidelines, rather than its own higher standards, is tacitly corporate policy. We might hope that the use case will be reusable whatever the pre-flight checks may be, but “hope” is not solid foundation…

A second place that business rules may lurk is within the definition and selection of actors. In your example, “a pilot” ought, perhaps, to be “the pilot”: the particular pilot for the flight. But perhaps it could be a co-pilot (for the flight), any of the airline’s pilot’s, or any person with certain minimum qualifications. Again, the business rules here may originate with the FAA or be further qualified by corporate policy (airline’s and, indirectly, airport’s). It may be necessary for “the pilot” to perform the checks, for example, but not to be the actor in the use case, or for someone else to perform the checks, overseen by “the pilot” who [currently] must be the actor in the use case.

Sepcific or generic? It seems necessary to define for any system the environment or milieu in which it is expected to operate. I’ve always called this the “operational context”, and business rules are a major part of this (especially if you add “facts” or “invariants” to your list of types). In recent discussions, it has been suggested that “operational envelope” may be a more appropriate term. The suggestion is that an “envelope” is a more generic environment than a “context”. I’m not sure that the terminology is important, but the critical factor is documenting appropriate limits to design to (relatively extreme environments rather than typical ones). Broadly speaking, the more extreme the limits, the higher the cost, so I treat the “operational envelope” specification as a multi-dimensional non-functional requirement. Since the supported variability of business rules translates directly into variability of the “operational envelope”, I hope you can understand why I find the idea of business rules not being requirements a little perplexing.

Scott Sehlhorst had a nice post today on Business Rules Hidden in Use Cases and, as I have not really talked much about rules and requirements on this blog I thought I would point my ebizQ readers to the post and,……