Your wrote: Use cases and business rules definitely work together. Because they represent fundamentally different considerations, you can choose the optimum way to separate them.
zarfman writes: Can you recommend any publications or other sources that can teach me how to choose the optimum way?
You could improve this by fixing two problems:
First, present the use cases with use case interactions, not system workflows. Your "use case" is really a functional spec.
Second, your "business rules" are in fact preconditions; they need to be true for the use case to succeed--quite possibly this use case alone. You need better examples.
To Zarfman: Thank you for your question. We use BPMN to represent process and siimple scenarios to represent the flow of use cases. We always use the Decision Model to represent business rules because they are not about flow, but about logic/thinking.
It turns out, when looked at it that way, business rules are as different from use cases as data is because business rules and data are declarative, not procedural. Use cases (and business processes) are procedural, all about sequence.
Ours is the only book (so far!) that provides a formal model for representing busienss rules as they relate to an entire holistic decision. A holistic decision is usually more than one Rule Family (i.e., disciiplined decision table). So, the model we present is what we use, just like people use a relational-like model to represent a holistic perspective of data.
If you want to learn more about the Decision Model notation, our book is the only reference so far. Also, we will continue to explain it in Modern Analyst (and we are presenting it at various conferences in the next few months).
Did I answer your question?
You are so right that we need better examples!!! Thank you for pointing that out. In an effort to keep it simple, perhaps the value of the representation is lost.
To your second point that business rules are pre-conditions, that is only a small part of the story. In any business process or use case, pre-conditions are tested so that the use case kicks off under proper circumstances. But there are many many "business rules" that are not pre-conditions at all, but are part of the "meat" of a use case because these are how the use case makes "business decisions". Let me give hopefully a better example than in the article.
Suppose there is a use case for determining whether a loan applicant is to be granted a particular loan. And suppose prior to that decision, there are pre-conditions about the data the applicant has provided. Once those pre-conditions are met, the use case may execute many separate decisions in order to conclude whether the applicant should be granted the requested loan.
One decision may be whether the Applicant's credit score is acceptable to the lending institution. There may be many rules about this based on the kind of loan, the amount of the loan, the payout period of the loan, and so forth. These may form an entire Decision Model (maybe 4-8 Rule Families connected together).
Another decision may be whether the Applicant has enough skin in the game. If the loan is a mortgage, the decisione may evaluate the value of the property versus the value of the loan and also include specifics related to different geographical regions. These may form an entire Decision Model (maybe another 4-8 Rule Families connected together).
Does this help? These are not pre-conditions, but are criteria to test in order to reach a business judgment (and those criteria need to change quickly due to market movement or catastrophic events, etc).
Ms. Von Halle
Zarfman writes: No you did not answer my question. My question is about optimality.
Your wrote: Use cases and business rules definitely work together. Because they represent fundamentally different considerations, you can choose the optimum way to separate them.
zarfman writes: specifically, by what means does one choose or determine the optimum way relative to separation use cases and business rules. Moreover, how does one prove the choice is optimal?
Zarfman writes: To me optimization requires the use of algorithms. These algorithms solve constrained and unconstrained continuous and discrete problems. these algorithms include functions for linear programming, quadratic programming, binary integer programming, nonlinear optimization, nonlinear least squares, systems of nonlinear equations, and multi-objective optimization. You can use them to find optimal solutions, perform trade off analysis, balance multiple design alternatives, and incorporate these optimization methods into other algorithms and models.
Marcthibault suggested better examples. I suggest FASB 157
I didn't say that business rules were preconditions. I said _those_ business rules were preconditions. On the other hand, there is an argument for the more general case.
I can't comment much on your example because you've put it in functional specification terms, not use case terms (Not unusual; functional specs are hard-coded into many analysts' viscera).
What I see are preconditions, what you see are flow charts. Use cases are known by the actor's goal. The use case isn't "Determine whether ..." It's "Get a Mortgage"; use cases are driven by ambition.
If the applicant's credit score is unacceptable, the use case will fail. That makes it a precondition. The algorithm for computing credit score is a business rule.
In not confusing a functional spec for a use case, the order in which success and failure conditions are tested is not material to a use case. A precondition is any factor that's required to successfully enact the use case. The "happy scenario" assumes that all the preconditions have been met and doesn't test for them. That's an implementation detail you leave up to the designers or programmers.
You may think it's not possible to test for a specific precondition until you are part way through the use case, but it remains a precondition. The programmer may be smarter than you.
The preconditions are a list of non-obvious statements that must be true for the use case to succeed. Some of them will be "this business rule has not been violated."
As much as possible, the designer will do what he can to prevent a use case from starting if the preconditions aren't met (you don't let someone start a process you know they can't complete), but that's clearly not always doable. A good designer will front-load the tests to minimize waste of the user's time. But that's design, not requirements.
Anyway, I've never met a business rule that was both relevant and not at least part of a precondition for some use case for some system. I've seen lots of design decisions masquerading as business rules, but they don't count.
I am sorry for not answering your question. But, I know why, and that is a disconnect in the intended meaning of the word "optimal."
Our work with business rules, Decision Models, use cases is done with business analysts and business SMEs (yes, we even have pure business people, like credit experts, who are not BAs creating Decision Models and "writing rules"). Wit that in mind, our intended meaning of the word "optimal" is as follows:
- business SMEs can understand the business rules/logic, correct it, analyze it, and sometimes even create it
- business SMEss are able to instigate and make changes to it with a quick-time-to-automation (agility)
- I/T is able to quickly automate the business rules/logic in that form or to generate the automation from it.
So, in our projects, these are the goals for optimum representation of business rules/logic that sit behind business-critical decisions behind use cases and processes.
Your insights into optimal design are excellent and valuable. So, they can be applied in the use case/BR/DM process also, but I see them happening after the business people are sure the rules are as they want or need them to be.
If you want more information, there is a public presentation given by a financial instute to MIT last month:
Again you are correct that the very simple business rules in the article would be considered pre-conditions by most.
Also, thank you for your clarification of my "Determine Whether an Applicant is Granted a Loan" is not a use case. My error. What we usually do is create business process models for decision-aware processes and then define use cases or scenarios and Visualizations on top of that. So, I stand corrected in that I worded it as if it were a "decision" or a "process" but not necessarily a use case.
Be that as it may, we are finding that in doing business process models, use cases, and business rules that the notion of a Decision Model (managed by business analysts or actual business people) is valuable because the same Decision Models are shared across use cases and across many business process models and systems. So, this elevates them to something of larger business value to business people, they actually see them as a new business asset (more business-centric than the idea of pre-conditions, although related). We are able to share and change Decision Models with less effort than otherwise.
Another realizatioin is that entire Decision Models can be shared (or even made mandatory) among different companies when those models have to do with regulations. The Decision Models can be the same but each company can build its own software (business processes, use cases, systems) around them. I think that is a realistic near future based on what we have seen.
Regardless, the sharing of decision models across use cases, processes, systems, and organizational boundaries streamlines adherence to the logic and also enhances proper governance for it because it is seen as a business asset and larger-grained deliverable At least that has been our experience to date.
As i indicated above, you can learn more at a recent presentation given to MIT last month:
The Decision Models are independent of the applications that put them to use and constitute a system (or system component), complete with use cases ideally named as and driven by questions. The actor's ambition is to have the question answered.
Depending on the level of automation involved, the actor is an anonymous software application or its programmer, not the application user.
The Decision Models are independent of application use cases, but not vice-versa. The link is application use case preconditions that are satisfied, or not, by enacting Decision Model use cases.
As is sometimes effective, the precondition might be turned into an "includes", perhaps named "Am I Credit-Worthy?" in this example.
Yes, yes! In fact, in some cases, clients implement an entire Decision Model as a decision service callable by anything that needs the answer to the decision's question! This is the technical perspective.
However, from the actual application user, the Decision Model is still visible (via looking at it in a repository) or also seeing the error messages that it generates.
A positive is that we can write use cases (or simulate them using Visualization software) without necessarily knowing all of the business rules up front. We can have a skeletal decision model in place and even an object model and fill it in iteratively until we get it right. We can also test decision models independently of broader testing which is turning out to be a tremendous boost to the testing approach.
Your comment about use case pre-conditions is intereting. We have wrestled with the pre-conditions involved with data quality (completeness of data, reasonableness of data values, and relationships among pieces of data) and have recently separated those from "business" decsion models. The DQ decision models are governed by data stewards while the "business" Decision Models are governed by other people (credit managers, etc). That way, we can share DQ logic across Decision Models and use cases, etc.
We have also created specific Views of Decision Models (much like a view in a relational database). So, we can have an "inclues of "Am I Credit-Worthy" and we can have a different View of the logic for each state, or each industry, or specific special customers, etc. This has turned out to simplify the management of corresponding business rules.
I think it would be worthwhile to explore use of the Decision Model and use cases in more detail with real-world examples (anonymous examples). If you (or any other readers) want to co-author something on this, that could be very useful!
Can i ask you two questions. Do you typically do an overall business process model for context and then define use cases on top of that? Have you done software visualization as part of requirements elicitation and if so, does that change the way you do use cases or does it solidify them and you still document them as fully as before?
Ms. Von Halle
Thanks for your definition of optimal; I have a better understanding of what you mean when you say something is optimal. I don’t agree with your definition, but such is life.
I checked out the Freddie Mac presentation at MIT as you suggested. Freddie Mac is a farce and so is Freddie Mae. Both entities were seized by the government because they were financial disasters bleeding millions in loses. Now the Treasury department has to figure out what to do with them. The shareholders aren’t too happy either.
I see your firm is involved in some manner – Congratulations.
If you want to tackle a real world example, try FASB 157.
Business model: always. The software exists to support a business process. Without a clear linkage to the business, the rationale for the software and the best arbiter of conflicts is lost. I do skeletal business use cases for the parts of the process that will be supported by the software, along with an informal presentation of the associations between business and system use cases. This part is about justifying the system use cases, not architecture.
For example, on a border services system project, the two business use cases were "Enter Canada" and "Bring Goods into Canada." You can see how that would color the system use case design.
Software visualization is also an integral part of the requirements deliverable. I like to use storyboards so I don't get bogged down by what color a button should be, and high level object models to pin down the key user-visible information. I document everything as fully as I can.
The idea is to have as many views as are necessary to make sure that no one can possibly misunderstand what has to be built. In that respect, if I've worn out everybody's patience with my questions and requests for feedback on the various artefacts, I consider it a job well done.
I have a blurb on use cases at http://smpro.ca/nb/usecases.html
Thank you for you explanations. I also read your blurb on use cases and I like it very much!!!
Do you have any favorite software tools for your uses cases and Visualization?
My normal tool is Word with embedded Visio diagrams and Excel tables.
I'll also have a "sketchbook" Visio file with many pages of pictures with heavy commenting (something like a graphic novel.) Visio is where I do the real work, Word is for presentation to stakeholders.
And then there's the client's thousands-of-dollars-per-seat Suite. The two I've used most are the RUP suite and Visual Architect/Paradigm. I still do the work in Visio, but I transfer it to the client's tool of choice when I'm happy with it.
The irony is that no one, not even the programmers, use the Suite output. The programmers take the use cases and my drawings and code from that. Without the automation straight jacket, my diagrams are easier to use.
Your message made me smile. I think your experience is shared by many. We do most of our business process models and decision models today with Visio (we have a visio plug-in for the Decision Model notation) and we use excel for our RF tables, linking them to the visio diagrams. (That said, I am looking forwar to upcoming Decision Modeling software - we just announced a software partnership in a press release yesterday with eDev for that).
We also have found that many (large) companies don't have a requirements software tool or aren't really using the one thay have.
I have one more question for you (do you have the patience for one more)?
What do you do with business rules? I am guessing that you don't put them into your use cases, but treat them as a separate functional requirement because, per your first comment, a use case aims for a goal, not for the answer to a specific set of business rules? Where and how do you store them? Or maybe they become a design artifact (which is also common practice, I didn't have that option in my article, I guess I don't like that option LOL!)
That's not a small question. It would be easier if we called them "policy statements" instead of "business rules"; it would put them in proper perspective.
The other part of the problem is that some business rules are preconditions and some preconditions are business rules, but not all.
In any case, I record them all. If some stakeholder can express a constraint unambiguously and no one objects, it's a business rule. We used to say that a mini-computer is a computer whose maker calls it a minicomputer; a business rule is a rule the client calls a business rule.
How I use that rule in the requirements statement is a whole nuther thang.
My discriminator is that failing a precondition means failing the use case; if it's possible to recover, it's not a precondition--it's an alternative scenario trigger.
Consider: "A property-secured credit line may not exceed 80% of the current property value." That's not a precondition, because the applicant can opt for a smaller credit line than their original request.
I include in the use-case, as preconditions, those business rules that impact the success or failure of the use case from the actor's perspective. Whether a precondition violation is discovered before the use case is enacted, or during, is immaterial.
Also keep in mind that business rules, if they are indeed business rules, will first appear in business use cases. The system use cases supporting the business use cases get them second-hand and possibly specialized.
Another thought. How will you know?
This applies to both post-conditions and would-be business rules. How will you know whether they've been satisfied?
If there isn't a use case that spills the beans, it doesn't matter what you call it because no one will ever know that you've ignored it.
I think i agree with most of what you said. I wouldn't, however, consider business rules or even policy statements to be something that should be "included in a use case" at all, but as something separate (in a Decision Model, of course) that the use case points to. And also, the surrounding business process also points to.
We tend to do business process models first and identify the list of decisions needing logic/rules (like credit score compliance, for example). We may create a whole decision model for important decisions even before we do use cases, especially if these are decisions that may seriously impact the business and if we know what the policies ought to be (dictated by regulatory agencies or required by underwriters, etc). We can build these models earlier than use cases sometimes.
Then we identify scenarios or use cases and these may also point to the full decision models (or just an anchor for them if they aren't developed). We do that with Visualization software.
So, I agree that rules/logic may surface during use cases (or earlier, or afterwards) but I don't agree with burying them in the use cases or anywhere else. For example, the rules behind Credit Score compiance can number in the hudnreds (or more) and that decision may be relevant to many processes or use cases and we want to reuse it (or create a customized view of it for specific business situations).
I think a difference between us is that we may be working with very decision-intensive applications which may not be the case in many industries.
When you say a business rule first appears in a use case, do you actually include it in the use case description or do you point to it elsewhere? Does it become a separate requirement? How do you accomplish reuse of rules and maintenance? Or maybe that comes later?
I am asking because we have tried all of the options in my article and usually, maintenance becomes a problem (except for the separate Decision Model).
(thanks for your patience again!)
How do you ensure reuse across use cases of the same policies or rules and maintain them?
I normally record all business rules in a business rule document of one kind or another, --Word or Excel. The advantage in using MS Office is that you can go beyond references or links and embed text from one document to the other so that updating the authoritative source updates all the copies. A wiki works pretty well too.
One of the bits of information with each business rule is a reference to at least one affected use case (ref How will you know). Orphans are ignored.
Where a business rule has the effect of being a precondition for a use case, I will include it as a precondition with a dynamic link to the text in the business rules. One thing I will not do is force the developers to trawl through multiple documents to figure out what to build (unless the client insists).
I definitely won't make them repeatedly explore all the business rules in case one of them applies to what they're doing. If it's not mentioned in a use case, it doesn't exist.
There's a use case design process impact here. It all works better and faster if you go against the flow. Start with the outputs (the consumer use cases) and work your way back to the inputs. It's the output use cases that create the demand for the rest. It's backward from the usual approach but it's far more efficient.
Thank you again. Essentially, you do it similarly to how we do it, although we put them in a model. So, we translate policy statements into decision model format (and we can tie those statements to their place in the model). Recently, we have imported the models directly into automation with minimal IT intervention so that policy changes can be automated very quickly.
I like your idea of ignoring orphans. We kind of have the same perspective, we have no where to put a policy/rule if it doesn't fit into a decision model of importance and which will be called by use cases or processes, etc. We also sometimes let the decision model (rules/logic) drive the data models and object models because if there is a piece of data we don't use, we don't need it! This sometimes seems backwards to people who create a data model and object model first and then use these for writing rules.
Anyway, thank you for sharing, I appreciate it. If you publish an article in modern analyst, let me know and I will be sure to comment .
One more concept in common. You said you start with the outputs of a use case and work backwards to the inputs. I love it, we do that with decisions!
For example, in a Loan Process Model, for the Decision "Determine Loan to Value Eligibility" we start with what are the possible outputs of this decision? Lets' say (eligible, not eligible, needs underwriter attention). We can stop there for a bit.
Next, if this decision is one to dig deeper, we then ask, what criteria do you need to make this decision. Let's say (Current Loan Amount, Other Loan Amounts on Same Property, Current Valuation of Property, Past Evaluations of Property, and so on). We can stop there for a bit. In fact, sometimes IT can start creating models and prototypes.
Next, we study policy statements related to this decision and how it is made using these criteria. Maybe we find more criteria, maybe we eliminate some, maybe some come from a database, maybe some come from other business rules (such as Other Amounts on Same Property, do we need calculations or more logic) and so we build the skeletal model. We can stop there for a bit.
Next (or in parallel), we start filling in the tables behind the model with translations of each policy statement and maybe we find we need to change the structure.
In the end, we eventually find out all of the persistent data we need as input which will (executing the whole model) give us one of the outputs we listed in the first step.
So, I, too, find value in doing things backwards! It also sparks business innovative thinking more often, we find. Like, why do we look at that? Who decided that criteria is important or that a certain value is acceptable.
Anyway, just had to share that on re-reading your comment again.
Greetings: Barbara and Marc:
This is the old finance and accounting dude.
I’ve been following your posts with interest and I like your train of thought. In dealing with IT which was typically under my control. I made sure as best I could that they were provided with the following requirements information;
All reports mocked up on paper/Word with information where to find the data and how it would be created if not in the system. The reports should also be displayable with up and down scrolling capabilities, etc.
Any calculations, such as compound interest with different compounding periods including continuous compounding and interest rates could vary over time.
A mockup of the input screens with error checking requirements, and copies of input source documents if required.
If some or all of the data was already in the system, I had IT copy the data to a developmental database. Then I would have one of my accountants introduce errors in the developmental data.
I also gave IT a list of people to call if they had questions.
This approach seemed to get the project of to a good start. I agree with your idea of starting with the output first. At least in worked reasonably well in my case. I never had a business analyst per se. The personnel in accounting and finance were the de facto business analysts.
With regard to business rules the Financial Accounting Standards Board and the IRS supplies us with lots of business rules, so we don't have to go hunting for them. Moreover, the rules often change over time. IT worked on methods to store the rules or create objects so we could hopefully avoid what IT called re-factoring.
I also tried to make sure that IT didn’t view accounting as the enemy and vice versa. I'm not quite sure if that worked or not.
I seem to be rather fond of the letter I.
Excellent, excellent input from you! Thank you. And the word "I" is very important when talking about business-focused participants, not to mention business leadership. And congrats to the accounting and finance personnel acting as business analysts.
Some of what you talk about can be done in a semi-automated way with Visualization Products. We do models first (process, decision models, sometimes data/object models), and scenarios/use cases. Then we, "visualize" (your mockups) using Visualization software to solidify the flow and to attach decision models/business rules to the right places in the flow and also add comments to that visualization per the business input. Sometimes we create protocasts, a video showing a typical user walking through the Visualization depiction, as if the software was already built.
This is very similar to what you are doing and it is working for you. We don't necessarily view the Visualization as a prototype for the final product, but more as another means for eliciting requirements we may have missed.
I would be intereste in other readers' experience with Visualization and what benefits were realized and when it is and isn't necessary or desirable.
Thanks Zarfman for your post!!!!!
It sounds like you're indulging in my favourite sport: Develop enough different views of the requirement that no one can possibly misunderstand what's to be achieved.
It works well for me too; you can never have too much information.
For sure that Use Cases and Business rules can sure work together.
I think that specifying business rules have allready to be started when modelling the processes. By leaving them out of the process spefications and only refer to them from the processes they are allready seperated.
Later on when Use Cases are specified to support some steps of the the processes, they can reference to the same rules (library) the same way as are referenced from the processes. For sure don't include them, because it will hard to manage.
I see often that thinking about business rules comes up when use cases have to specified. Because then questions come up wat has to be checked, and what has to happen when it is not valid etc. And then the rules are suddenly owned by the IT project and not by the business. It should be done and owned by the business. Of course the system analyst can help.
By using a modelling tool (Sparx Enterprise Architect) instead of Visio, or Excel for rules, processes and use cas models, you can make a full model (including traceability relations) which offers different ways to do analysis on the information available in the model. For example a rule can be selected and the tool shows by which parts in the processes it is used and also which uses cases. And viceversa when selecting a use case or part from the process the used rules are shown. Of course this information has to be entered in the model and connected to each other. The tool I use also support the modelling of decision tables as you proposed in the article.
Information which is not specified easy in a model is still specified in Word and Visio and referenced from the elements in the model. Also because the readers are not used to it when presenting it another way. For example sketches of screens are we doing in Visio or other screen prototype tool. Exmaple of letters and reports are specified in Word. Full Use Case specifications is done in Word, but we are looking for a way to do it more structured way to enter it in the model and from there generate a Use Case
You make some excellent points, so I would like to re-iterate them.
1. I think that specifying business rules have allready to be started when modelling the processes. By leaving them out of the process spefications and only refer to them from the processes they are allready seperated.
Outstanding! The one common "gotcha" is if rules or parts of them are incorrectly modeled as process. For example, if a process model has a task for "Evaluate Credit Score" and the next task is "Evaluate Income" when, in some cases, these are simply conditions in rules that can sit behind one task for "Evaluate applicant's ability to pay" or something like that. But, as time goes on, we become more experienced at recognizing the difference between "process" and "logic/rules".
2. Later on when Use Cases are specified to support some steps of the the processes, they can reference to the same rules (library) the same way as are referenced from the processes. For sure don't include them, because it will hard to manage.
3. I see often that thinking about business rules comes up when use cases have to specified.
Yes, often, but not always. If a process is very decision-intensive (such as making credit decisions), it is possible to identify discrete decisions while doing the process model, then complete the entire set of business rules behind each decision prior to doing use cases.
OTOH, sometimes many or most of the rules do surface while doing use cases because we start to focus on details.
We find it useful to do it the first way because, while the business rules are truly the details, the entire decision (set of business rules) is the bigger picture and most often can get more management attention. IOW, the whole decision is seen as more than the sum of its parts.
4. And then the rules are suddenly owned by the IT project and not by the business. It should be done and owned by the business. Of course the system analyst can help.
This is a wonderful point! They should be "stewarded" by the business and they should remain readable and changeable by the business in a business-friendly form. I think some commentors have stated that the tools for doing so (including the traceability) are not simple for business people to use. And I think that is where we lose the business connection. What do you think? How can we keep them better connected to the rules?
5. By using a modelling tool (Sparx Enterprise Architect) instead of Visio, or Excel for rules, processes and use cas models, you can make a full model (including traceability relations) which offers different ways to do analysis on the information available in the model.
I totally agree. What we need are friendlier interfaces for business people for the raw rules/logic and the business analysts or systems analysts can make the useful connections.
6. Full Use Case specifications is done in Word, but we are looking for a way to do it more structured way to enter it in the model and from there generate a Use Case
An intriguing thought. I think of use cases rounding out models, but it would be interesting to be able to generate use cases.
Thank you for your input! I think it is valuable to most readers.
This article really opened my eyes to new approaches for analyzing business requirements. However, the authors didn't mention anything about how business rules relate to User Stories. How could we use the same approach used here for Agile Projects?
Where you read Use Case, think User Story. They aren't quite the same but in the context of this discussion, they're close enough.