Documenting Business Rules in EA

[operaman]

I've only been working in EA for about a month so please excuse my newbie query about business rules.  I am principally using EA to capture requirements, Use Cases and workflow (modeled so far as Activity work flow and a UI model). I know that there is a technique that can be used to "externalize" (Move External) requirements that may be documented while fleshing out the properties of a Use Case.

Is there a similar technique that can be used to 'externalize' the business rules (constraints) of a requirement via the 'Rules and Scenarios' dialogue? The reason I ask is because the 'Rules and Scenarios' are somewhat 'hidden' in the overall model. It's also not very apparent/intuitive as to how a (new) user would view this dialog for a given requirement element (ctrl+shift+3 - as opposed to dbl-click).

How would a tester or developer use an EA model to find / list all Business Rules in a given model (that have been created using the 'Rules and Scenarios' dialogue?

Thanks!

[Thelonius]

operaman

I don't have the answer to your question, being a newbie to EA myself, and using it for different stuff anyway.

But your question and the way you've explained it has to be the most well-written, coherent question I've seen posted on this forum.

Well done.

I'm also interested in tracking the answers you get, because this may be of use to me too, some day.

Cheers

Jon

[Dorian Workman]

IMHO I think you might be over complicating things.  I simply create a Requirement element for each of my Business Rules, with stereotype of <<Rule>>.  I haven't encountered a scenario where a Requirement needs more Requirements, either Internal or External.  In fact the Requirement element doesn't support adding Requirements to Requirements at all.

Perhaps your Requirements are big?  I keep my Requirements pretty granular.

As to the Rules & Scenarios view, I think it is intended to be used to look at Use Cases, and their Scenarios & Requirements. At least that's how I use it.

I hope this helps...

[operaman]

Hmmh. Maybe I am overthinking it or trying to make things too complex in my model. CIP (case in point) it took me a couple of minutes to figure out what IMHO means.

So if I understand you correctly - you simply create business rules (in a separate rules package) as requirements using a <<rule>> stereotype. The <<rule>> is not one of the native / original defined types for a Requirement element. Did you create a (new) <<rule>> stereotype yourself using Settings --> General Types --> Requirements tab on on the General Types dialogue box?

If I model Business Rules in this fashion, will I be able to associate business rules with Use Cases or other Requirements elements?

Thanks.

[bioform]

Yes, if you associate the BR to the UC as a realization, then the requirement will be listed under the UC's requirement tab (external requirement)

Also the use of an RTM view to "show" that all BRs have been allocated would be helpful I believe.

Maybe we can each share our approach to modeling BRs within an EA model...

David

[Dorian Workman]

Hmmh. Maybe I am overthinking it or trying to make things too complex in my model. CIP (case in point) it took me a couple of minutes to figure out what IMHO means.

So if I understand you correctly - you simply create business rules (in a separate rules package) as requirements using a <<rule>> stereotype. The <<rule>> is not one of the native / original defined types for a Requirement element. Did you create a (new) <<rule>> stereotype yourself using Settings --> General Types --> Requirements tab on on the General Types dialogue box?

If I model Business Rules in this fashion, will I be able to associate business rules with Use Cases or other Requirements elements?

Thanks.

Yes I created the new <<Rule>> stereotype exactly as you said.

There's super-simple way to create the Rule and create the Realization link with the Use Case.  

1. Create a Package in your model called 'Business Rules', or whatever you like.

2. Double-click on a Use Case element, go to the Requirements tab.  Type the name of your rule into the Requirement field, the details of the Rule into the large empty field (that's the Note field, unlabeled here), then select your newly-created <<Rule>> stereotype from the Type dropdown.  Click Save.  You'll see it in the list below - note the 'External' column is blank.

3. Click 'Move External', locate your Business Rules package, click OK.  Note the 'External' column now says Yes.

4. Now go to the Use Case's 'Links' tab.  You will now see a 'Realization' relationship between the Use Case and the Rule (a Requirement element, with stereotype 'Rule').

Voila.

Another easy way to create the Realization relationship is to create the Rule in your Business Rules package first, then simply drag and drop it onto the Use Case when the use case is on a diagram (you can't just drop it onto the use case in the Project Browser.

Good luck.

[bioform]

Well explained Dorian.

It is a nice feature to be able to drag and drop (e.g., Requirement ONTO the Usecase) to create the realization.

[Dorian Workman]

Thank you!

[Ainsley Haslett]

For documenting rules I use the requirement element. I create a diagram and then add a package called requirements and another package called rules.

When you add a rule add the requirement element to the diagram and then move it in the browser into the rules package. In this way the diagram will identify the element as being 'from rules package' or 'from requirements package' and the move external function is the same for a rule as a requirement.

The last thing you can do is add a new Type of 'Rule' so when you add a rule you can set the type to 'rule' instead of 'functional'. To set this up go to:
Settings > General Types. Requirement tab. Add a new item called 'Rule'.

Hope this helps, it worked for me...

I've only been working in EA for about a month so please excuse my newbie query about business rules.  I am principally using EA to capture requirements, Use Cases and workflow (modeled so far as Activity work flow and a UI model). I know that there is a technique that can be used to "externalize" (Move External) requirements that may be documented while fleshing out the properties of a Use Case.

Is there a similar technique that can be used to 'externalize' the business rules (constraints) of a requirement via the 'Rules and Scenarios' dialogue? The reason I ask is because the 'Rules and Scenarios' are somewhat 'hidden' in the overall model. It's also not very apparent/intuitive as to how a (new) user would view this dialog for a given requirement element (ctrl+shift+3 - as opposed to dbl-click).

How would a tester or developer use an EA model to find / list all Business Rules in a given model (that have been created using the 'Rules and Scenarios' dialogue?

Thanks!

[bioform]

I use a collection of stereotyped requirements with tagged values and supporting enumerations:
E.g. Requirement Types (TBD, BusReq, BusRule, AcceptCrit, SysReq, Definition) added to Settings/General Types.

Then I just drag the appropriate stereotyped requirement from resources onto the diagram, etc.

Example: BusReq
- Category=Business
-Type={Term, Fact, constraint,Action Enabler, Infrences, Computation, Not Specified}
- Rationale
- Comments

If anyone is interested I could send or post...

David

[Oliver F.]

Most things have already been said except that we are using a stereotyped use case element to describe business rules and distinguish from use cases - much more flexible.

The reason I ask is because the 'Rules and Scenarios' are somewhat 'hidden' in the overall model. It's also not very apparent/intuitive as to how a (new) user would view this dialog for a given requirement element (ctrl+shift+3 - as opposed to dbl-click).

If you want to get away from the "hidden" aspect of scnearios then yu can add a note to the diagram with the business rule and link it to the the scenario of the element (in fact it will work with most other information from the properties dialog, too). This will visualise the hidden information.

Just as a side note.

Oliver

[bioform]

What do you see as the advantages of "modeling" a business rule as a use case, rather than referencing a bus rule in a use case? I'm not sure I am following your approach.

In my approach, I make the assumption that a business rule may be applicable to one or more scenarios of one or more use case. The business rule (as a requirement) is independent of the system, in that by definition, a business rule will continue to exist even if the system is never built... (e.g., All Orders from Delinquent Accounts must be approved by a Manager)

The BR may be realized in the system many different ways, but if it is within the scope of the system, then it will be found in at least one Use Case, I would believe.

Side Note about "Notes"
ALSO you MUST be careful, because a NOTE only exits on the diagram, NOT as an element. So if you "copied" that note to another diagram, then someone else decided that NOTE was not needed and deleted it... IT WOULD BE DELETED from the MODEL and from ALL diagrams that use it...

[fballem]

Modelling a Rule as a Use Case is particularly useful for a complex rule, such as a Customer Approval.

If a Business Rule is simple, then I model it as a Requirement and link it to any other items to which it applies.

If a Business Rule is complex, then I model it as a Use Case, with Scenarios briefly described. I will then put in an Activity Diagram to model the Rule detail. Linking the Use Case to where it applies then ensures that the reader can go to an appropriate level of detail.

Hope this helps,

[bioform]

It seems like we are talking about two different things here... Everyone seems to have a different meaning of a business rule, so it might be helpful to view some of the following links to see from our industry POV the meaning of these terms:
http://en.wikipedia.org/wiki/Business_rule
http://www.businessrulesgroup.org/home-brg.shtml
The use case you mention is a description of the interaction between an actor and the system. The goal of the use case (getting approval) is constrained by the business rules specific to this workflow/process. These business rules should be to be stated as individual requirement statements.  It is not uncommon for the same BR to be applied in more than one use case or other analysis artifact (e.g. business domain model.)
A business rule does not have scenarios, but can and should be able to be mapped to one or more use cases and their specific scenarios that help place the BR in the proper context. Then the implementation of a BR can be explored during design, but the actual BR is in fact a requirement statement.
IMO it is important to keep these concepts clear and precise in their meaning and to follow best practices when applicable. BRs are indeed one of the most important parts of a system’s requirements.

[Dorian Workman]

Well put, I completely agree with you bioform.

It seems like we are talking about two different things here... Everyone seems to have a different meaning of a business rule, so it might be helpful to view some of the following links to see from our industry POV the meaning of these terms:
http://en.wikipedia.org/wiki/Business_rule
http://www.businessrulesgroup.org/home-brg.shtml
The use case you mention is a description of the interaction between an actor and the system. The goal of the use case (getting approval) is constrained by the business rules specific to this workflow/process. These business rules should be to be stated as individual requirement statements.  It is not uncommon for the same BR to be applied in more than one use case or other analysis artifact (e.g. business domain model.)
A business rule does not have scenarios, but can and should be able to be mapped to one or more use cases and their specific scenarios that help place the BR in the proper context. Then the implementation of a BR can be explored during design, but the actual BR is in fact a requirement statement.
IMO it is important to keep these concepts clear and precise in their meaning and to follow best practices when applicable. BRs are indeed one of the most important parts of a system’s requirements.