Author Topic: Documenting Business Rules in EA  (Read 4422 times)

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Documenting Business Rules in EA
« Reply #15 on: January 13, 2009, 07:04:46 pm »
Quote
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.

Correct and this is one of the reasons why a BR can be modeled as a stereotyped use case. This keeps the concepts separated and clear without leaving you alone with the task to describe a complex BR as a simple requirement => Best practice.

From an abstract point of view a UC is some sort of (extended) requirement so it is legitime to handle a BR like this.

Oliver

Oliver

bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Documenting Business Rules in EA
« Reply #16 on: January 14, 2009, 09:20:00 am »
I could not disagree more. A use case is by no intent a representation of requirements! It is a tool to be used to identify the flows (aka scenarios) of a interaction with the SUD. As a result of doing the use case /scenario driven analysis you discover the requirements and then document them and at least map them to the usecase, if not to the activities and actions identified in the flow as responsibilities that the system has to meet.

Also the whole point of the analysis is to take these \"complex" business rules and break them down into descrete requirements and to decide which ones are within nthe scope of the system, and identify what parts of the interactionsw with the system they apply to. This way the desiugners (after validation of course) can understand the BR requirements in their proper system contect.

Using Use Cases for not what they were intended is not following best practicies. We all have success by standing oin the shoulders of those who have gone before us,

No offense intended, but I think it would be good to review/discuss the use of use case in analysis. There have been some excellant discussions on this formum concerning use by some very experienced engineers.

Regardless I wish you continued success and a great 2009!

« Last Edit: January 14, 2009, 09:24:17 am by bioform »
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Documenting Business Rules in EA
« Reply #17 on: January 14, 2009, 06:20:43 pm »
Quote
I could not disagree more. A use case is by no intent a representation of requirements! It is a tool to be used to identify the flows (aka scenarios) of a interaction with the SUD.

What exactly lets you believe that scenarios and flows are not requirements ?
The analysis phase (often performed by requirements engeneers) is by all means meant to identify requirements for the later design and implementation of which use cases, business rules and NFRs are some types of them especially in complex environments for capturing very high level scenarios. Just because one calls it "scenario" does not make it a non-requirement for later phases especially if several teams are involved in there.

And this is best practice, succesfully practised and proven over a dozen of years (and personally discussed with Craig Larman, btw ;) ).
So I consider myself being one of those "very experienced engeneers" :)

Oliver

[edit]
I believe the misunderstanding between our points of view is based on the term "requirement" which you are taking much stricter. However in terms of process and flow this is not adequate enough- a requirement/concept is a requirement for analysis, an analysis artefact (like UC,...) is a requirement for design/test/deployment, a design document is a requirement for implementation, etc. [/edit]
« Last Edit: January 14, 2009, 06:35:06 pm by ofels »

bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Documenting Business Rules in EA
« Reply #18 on: January 15, 2009, 02:47:01 am »
I believe the definition of a requirement has been defined by many in the requirements engineering field. A good definition that I like is from: Scenarios, Stories, and Use Cases, by Ian F. Alexander and Neil Maiden (Wiley publishing 2004) – Page 509 of the Glossary (Requirement)
“A statement that a System is to satisfy, whether
a)      By providing a desired Functional result such as may be delivered by Scenario or Scenario Step;
b)      By having a desired quality such as a given measure of performance or reliability (a Non-Functional  Requirement or ‘-ility”;
c)      Satisfying some external Constraint such as an interface definition or a physical size, power consumption, and so on.”

There are many other good definitions of a requirement, and identify what makes a requirement “good.”
“Software Requirements”,  2nd Edition, by Karl E. Wiegers. The following is a list of the paragraph headings that occur under a section titled “Requirement Statement Characteristics” (page 22 – 25):
Complete, Correct, Feasible, Necessary, Prioritized, Unambiguous, and Verifiable.
He goes on with a section titled “Requirement Specification Characteristics” specific to “sets of requirements that are collected into a specification…”:
Complete, Consistent, Modifiable, and Traceable.

A scenario is a specific set of steps to describe one interaction with the system (e.g. a specific pathway through an activity diagram) used to both elicite, verify, and validate requirements for the goal of that use case.

If an activity diagram is being created for a use case, then following good practices, their should not be more than 3 - 10 steps. So the scenarios of a use case should NOT be inordiately complex. If they are it may be indication of a need to re-factor the use case into one or more additional use cases. The steps are NOT requirements for the design, but merely a way to discuss a conceptual interaction with the system as part of the analysis process.

The scenarios of a use case can also be a great way to review requirements within a business context, limited by the chosen scenario (this helps keep the scope of the review small and precise) and by the stakeholders of the system (users, developers, customer, etc.) with the goal of getting agreement that the requirements specified are both correct and robust enough to meet the needs of the users and the design/development team.

Remember that the scenario steps DO NOT and SHOULD NOT be constraints on the design (unless they have been and are intended to be constraints), but the scenario goals MUST be able to be attained by the solution and verified through testing that the requirements have been met.
 
A UseCase, an Activity Diagram, a Scenario are NOT requirements, they do not meet the definition of a requirement. They are analysis artifacts used to elicite and verify the requirements of the system.

I'm sure you can find many other good sources on the web, in books, etc. that clearly specify what a requirement is and the characteristics of “excellent” requirements.

On a side note:” Please try to keep a civil tone. In trying to make our point we should not name drop, brag about our experience or background. But try to answer the questions of comments with examples, clarifications, suggestions, etc. It is easy when reading a post to mistake enthusiasm for a point-of-view or opinion for something else which may have the affect of limiting the discussion or keeping other forum members from posting their comments.

Thanks, David
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Documenting Business Rules in EA
« Reply #19 on: January 15, 2009, 03:44:34 am »
I have removed the remaining of the quotations as the relevant part to comment on is here:

Quote
A UseCase, an Activity Diagram, a Scenario are NOT requirements, they do not meet the definition of a requirement. They are analysis artifacts used to elicite and verify the requirements of the system.

Please read the edited part of my last post- I believe I have clearly stated the different views. Every output artifact of a phase is also a requirement input artifact for the next one. This is an undeniable fact.

The term "requirement" can on the other hand be used very strict and formal (as you did) in your post. I totally agree with you that the requirement (as you see it) and the scenario are seperate things.
One will not find terms like "SHALL", "SHOULD", etc. in scenarios.

What we are argueing about here is just the word "requirement" which is used in two different contexts and means similar, but not not identical things:
A (eg. customer) requirement like "must be showing a green light" and the scenario ("shows a green light") which serves as a input requirement for designers, developers and system testers.

Quote
On a side note:” Please try to keep a civil tone. In trying to make our point we should not name drop, brag about our experience or background.

The tone used still appears to me having been civil. If it did not sound like it it might also be the result of the language barrier which might lead to misunderstandings.
I believe that pointing to locations where "very experienced engeneers are" also falls under the "civil tone keeping" requirement? ;)


bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Documenting Business Rules in EA
« Reply #20 on: January 15, 2009, 04:53:28 am »
I agree that we are talking about two concepts (project requirements and solution requirements.) Supplying artifacts to the different phases of the project are requirements based on a project management process.

I feel that the thread has gotten off the point. Perhaps if the original poster "operaman" could give us a simple example of a business rule that he is attempting to model in EA, we could both provide examples to him of our different approaches and they could be evaluated and we could all learn from each other.
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Documenting Business Rules in EA
« Reply #21 on: January 15, 2009, 09:54:19 pm »
Quote
Perhaps if the original poster "operaman" could give us a simple example of a business rule that he is attempting to model in EA, we could both provide examples to him of our different approaches and they could be evaluated and we could all learn from each other.

The topic of business rules btw is a rather difficult one as the understanding of BRs highly differs.
My experience is that depending on the industry, overall system complexity and background of the authors business rules are applied differently.
Applying BRs ranges from using them to capture business strategies to seeing them as some sort of black box to throw in everything which does not belong into a use case or a NFR (algorithmical issues, infrastructure requirements, internal processes).
Additionally the borders between use cases and business rules are blurring in certain practical aspects-.
For example in the last years business rules have been inappropriately applied in our system development which now renders most of them rather useless. As a consequence I have decided to temporarily remove them from the process until we have found an appropriate way of applying them and what we would like to achieve by using those.
What I would like to emphasize here: As with most artifacts, writing BRs just for the sake of having them is a rather suboptimal approach.

Oliver

bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Documenting Business Rules in EA
« Reply #22 on: January 17, 2009, 06:52:38 am »
You definitely "Hit the Nail on the Head"

Most of the time, when we are talking about BR in the requirements realm, we are actually talking about those fragments of a BR that are considered within the scope/responsibility of the system under design.

So it is important to be able to specify the requirements for these BR fragments in a concise correct manner. However you decide to do that, as long as it meets the needs of the project (management/developers) and it correctly identifies the "rules" the customer expects the system to implement, then it is fine.

It makes no sense to model something that might be “more correct” in someone’s opinion if it does not communicate clearly what the requirements/responsibilities of the system are.

I believe it would be of value for us to share examples of BRs we have encountered in our projects and give examples (does not have to be in great detail, maybe just walk through the conceptual/modeling approach) that we can comment on. Maybe start a seperate thread...

We could of course use a example we all are familiar with the:

ATM - Cash Machine

Example: BR - Do not allow the customer to withdraw funds in excess of their account balance available for withdrawal.

This appears simple enough, if we have modeled the domain, agreed upon the “terms” and have identified/defined the other business rules that this one is dependent on...

For example WHAT are the BRs for determining "Available Account Balance for Withdrawal"

There may be other BRs that this BR is dependent on, or used to calculate the available balance such as:

  • Hold Time for Non-Cash Deposits,
  • Hold Time for Foreign Cash Deposits (rate in affect at End of Day Market Close)
  • Deposits reserved for Check Protection Service
  • Deposits reserved for Minimum Account Balance
  • Customer able to Withdrawl Funds as Cash Advances on the Account, etc.

I think it would be great and very helpful to see a fully fleshed out ATM example that could be used to demonstrate the capabilities of EA that are directly linked to a project example...
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Documenting Business Rules in EA
« Reply #23 on: January 19, 2009, 11:20:44 pm »
Quote
I think it would be great and very helpful to see a fully fleshed out ATM example that could be used to demonstrate the capabilities of EA that are directly linked to a project example...

Well, again it depends on the stakeholders and intention of that BR.
Eg. it can be valid for a BR to describe the terms "Withdrawal" and "Transaction" algorithmically from a requirements point of view (eg. "before a withdrawal 10% of fees shall be added to it but not more than xxx US$ and not less than yyy US$") which is a business requirement but also a scenario ("before a withdrawal 10% of fees are added to it but not more than xxx US$ and not less than yyy US$"). So where does it belong to? Requirements or Scenarios?

Infrastructural considerations might also be included: "The ATM is connected through a secured VPN to the transaction server using firewalls". This is an important information as it means that the developers do not need to consider additional encryption mechanisms to it. However it is also valid as an assumption- "we assume that the ATM is connected via VPN...".

How about logging and data structure considerations: "The operator opens the logging application, selects a log entry and inspects date of transaction, customer ID, amount of withdrawal and ATM location".
This can be seen as 3 types of information: A scenario, a data structure ("log entry=...") and algorithmical requirements ("each entry shall be logged with date, ID, amount and ATM location").
Of course it can appear as all three types but then we have redundancies.

Having lots of stakeholders in the requirements and analysis phase makes it rather difficult to choose which is the best approach especially if the interests overlap. You end up with a matrix of interests and to satisfy all needs it can be a solution to narrow the types of artifacts to the bare necessary for a certain purpose- like eg dropping BRs. Especially if those are not needed in the later process and just serve for documentation purposes and nothing else.

In short terms: Define the overall purpose for business rules and relate it to the stakeholders first. Then decide what to do.

Oliver

bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Documenting Business Rules in EA
« Reply #24 on: January 20, 2009, 01:40:07 am »
Oliver,
I will no longer be posting to this thread as it appears it is just the two of us saying/repeating the same thing. I respect and am glad you posted your thoughts and comments.

Thanks, David
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>

Elham

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Documenting Business Rules in EA
« Reply #25 on: January 28, 2009, 08:54:27 pm »
What's different between Business rules and constraint??

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Documenting Business Rules in EA
« Reply #26 on: January 28, 2009, 09:28:13 pm »
Quote
What's different between Business rules and constraint??

A constraint does not actively contribute to a scenario- it merely defines environmental aspects which are of the boolean type. An example is a precondition- it must be true so that a scenario can be passed.
Or an assumption- it must be valid to enable the scenario to be passed.
A limitation falls in the same category.
A constraint has implicit implications, not explicit. If we assume that a connection line is encrypted the developers do not have to care abour additional encryption measures. If a precondition is not met then an exceptional scenario has to define what should be done in that case.

A business rule describes explicit actions to be performed by the system- an algorithm, structural or infrastructural aspects, domain object structure, etc. which directly map to system behavior.

Oliver

Henrique Narciso

  • EA User
  • **
  • Posts: 86
  • Karma: +0/-0
    • View Profile
Re: Documenting Business Rules in EA
« Reply #27 on: February 10, 2009, 08:53:12 am »
Hi all,

great thread!

we want to use Business rules, to document specific domain requirements. so far so good.

however we also want to use the Auto name counter function to automatically define the BR.

How can I create a new element type that may be a target of an auto name counter rule?

I have searched in the uml profile section but I don't see the solution there.

Any ideas?
« Last Edit: February 10, 2009, 09:00:48 am by hnarciso »

bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Documenting Business Rules in EA
« Reply #28 on: February 10, 2009, 09:24:33 am »
I would encourage you to see the new capability built into the upcoming release 7.5, quote from help file:

"Business Rule Modeling is available in the Business Systems Engineering edition and Ultimate edition of Enterprise Architect.
 

To model Business Rules in Enterprise Architect, you work through the following steps:

Create a Fact model, which provides the business vocabulary for defining business rules.
Create a Rule Flow model, which provides the order in which the business rules are executed.
Create a Rule model to define business rules and relate them to a specific Rule Task.
Model the rules in the Rule Composer, which enables the rules to be transformed to a logical level of detail.
This process completes the modeling of Business Rules. The Fact model can then be transformed into the appropriate code using Enterprise Architect's general code generation methods. This generates the technology-specific business rules; that is, the code to execute the business rules.
"
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>

Daniel Beahan

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Documenting Business Rules in EA
« Reply #29 on: February 12, 2009, 09:13:40 am »
Quote
Hi all,

great thread!

we want to use Business rules, to document specific domain requirements. so far so good.

however we also want to use the Auto name counter function to automatically define the BR.

How can I create a new element type that may be a target of an auto name counter rule?

I have searched in the uml profile section but I don't see the solution there.

Any ideas?

Hi Henrique,

I am having the same issue and I couldn't find a way to do it.  I decided to add the business rules using the Feature type rather than the Requirement type.  I have no need to use the Feature type for anything else and it maintains it's own Auto Name Counter distinct from the Requirement type.  You can stereotype it to be a Rule as well.  It's a workaround rather than a solution but it may allow you to do what you want to do.

Regards,

Daniel