Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Should Business Rules be in a seperate document
Previous Previous
 
Next Next
New Post 5/28/2011 4:30 PM
User is offline sraaj
3 posts
No Ranking


Should Business Rules be in a seperate document 

 The best practises says Business rules should  be documented in a seperate document.  is this right

I have seen use cases with business rules being done. Is trhis correct

 

what should be the right format for business rules.

 

 
New Post 5/29/2011 5:26 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Should Business Rules be in a seperate document 

 Hello sraaj,

There is no one right way when it comes to business rules.  Or any form of requirement for that matter.

Here are some questions to help you think through how to manage this content;

  • Who needs to read it?
  • Is it project specific or will thee rules be reused in later projects?
  • Are the business rules specific to one solution/sysytem, or are they generic rules of the whole organisation?
  • Could people in other teams make use of this content?
  • Is it too much to digest in one packaged form?
  • Are there sensible ways to partition or decompose the sets of business rules you are handling?

As for the phrasing of business rules; there is no current recommended best way, although if you search the internet (eg the business rules group) you'll see some guidelines.  The general guidance is specific, and unambigous, but plain user oriented langauge.

 
New Post 5/30/2011 1:42 AM
User is offline Kimbo
456 posts
5th Level Poster


Re: Should Business Rules be in a seperate document 
Modified By Kimbo  on 5/30/2011 4:45:42 AM)

 Hi Sraaj,

Its a good idea to list your business rules in a separate register. This is because the relationship between business rules and use cases is many to many, so if you put them in your use case you're in danger of having to update the one rule in multiple places. You will need to link your business rule to the use case(s) it is associated with. A modelling tool will make this easier for you. Doing it just using ms word is trickier and can potentially make your document harder to read. Bit of a trade off between best modelling practice and readability.

If you keep them in a separate document that will make it even harder to read unless you can automate pulling the business rule into the use case document. 

Kimbo

 
New Post 5/30/2011 5:17 PM
User is offline KJ
243 posts
6th Level Poster


Re: Should Business Rules be in a seperate document 

Sraaj,

Business rules govern the system's behaviour; and usecases capture this behaviour.

Example one business rule could influence 1 or more use cases; or one use case satisfies 1 or more business rules. From an ERD perspective, it’s a many to many relationship, which is resolved with an RTVM (requirements traceability verification matrix) that links the use cases with business rules. It also has the added benefit, that when a business rule changes, you know which use cases are affected, and if a use case (behaviour) changes, You'll check to see if it still satisfies the business rule constraints.

So you best practice assertion is correct! yes, keep them separate!

warm regards,

K

 
New Post 10/29/2011 3:02 AM
User is offline garagedoors
8 posts
10th Level Poster


Re: Should Business Rules be in a seperate document 

yes ,

 

Business Rules be in a seperate document.

its such a good idea........

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Should Business Rules be in a seperate document

Community Blog - Latest Posts

As Business Analysts in Agile teams, we often hear about Definition of Ready (DOR) and Definition of Done (DOD). But beyond the buzzwords, these two concepts are powerful tools to drive clarity, consistency, and quality in our work. Definition of Ready ensures a user story is truly ready for development. It answers: Is this story clear, feasible...
In today's fast-paced digital world, successful projects aren't just built on great code—they're built on clarity. And that clarity often comes from one key player: the Business Analyst. At the heart of every great product or system is a need—a business goal, a customer pain point, or a regulatory requirement. But busines...
I have always loved cooking. I learned from my Grandma June and her kitchen was her sanctuary, a small, warm sunlit space filled with jars of spices, stacks of cookbooks, and the comforting smell of something always on the stove or baking in the oven. Grandma June was as great a cook as she was a teacher to me. She never followed a recipe “to...

 






 

Copyright 2006-2025 by Modern Analyst Media LLC