So where do we place Business rules? In the use case or separately?
Well its at the discretion of the Business Analyst. According to me, Business rules should be kept separate because:
If use Cases are documented in Word then business rules can be written as a part of Use case.
However creating a matrix of Business Rules and Use Cases enables the business analyst to maintain and avoid rework on each use case.
An effective way of presenting a business rule is to emphasize on only 1 concept. They govern an organization regardless of the process/work flow followed to achieve them. For example achieving sales target. Business Rules can be:
- Name: One liner.
For example: Minimum funds required for investment.
- Unique Identifier
For example: BR 001
- Description: It describes the rule in detail. This can be explained in text or UML activity diagram if there is an algorithem required.
For example: The investor needs to maintain minimum funds of $100,000 for investing in new hedge fund strategy. If investing in an existing strategy then minimum requirement is $50,000.
- Source : It can be reference document or any business user name.
- Related rules : To maintain tracebility.
- Revision History : Description of the change, who made the change and when was it made.
- Effective Date: Date from which it is valid.
- Expiration date: Till when its valid
Maintaining Business Rules
Best way to maintain business rules is in X - Y Matrix. This Matrix creates a link between FR ID and UC ID. So anytime business analyst needs to update a business rule, it just have to go to the matrix rather than eah individual use case.
If we talk about Agile methodology then UML Activity diagrams are the best way to communicate requirements. In the previous post we mentioned UML Use case diagrams as well.
So it makes sense to move to UML Diagrams.
Well its at the discretion of the Business Analyst. According to me, Business rules should be kept separate because:
- Business rules can be used across many use cases
- They change often than the Use Cases
If use Cases are documented in Word then business rules can be written as a part of Use case.
However creating a matrix of Business Rules and Use Cases enables the business analyst to maintain and avoid rework on each use case.
An effective way of presenting a business rule is to emphasize on only 1 concept. They govern an organization regardless of the process/work flow followed to achieve them. For example achieving sales target. Business Rules can be:
- Access control issues
- Derivation: Pertaining to business calculation
- Policies of the organization
- Constraints: enables or prohibits action
- Name: One liner.
For example: Minimum funds required for investment.
- Unique Identifier
For example: BR 001
- Description: It describes the rule in detail. This can be explained in text or UML activity diagram if there is an algorithem required.
For example: The investor needs to maintain minimum funds of $100,000 for investing in new hedge fund strategy. If investing in an existing strategy then minimum requirement is $50,000.
- Source : It can be reference document or any business user name.
- Related rules : To maintain tracebility.
- Revision History : Description of the change, who made the change and when was it made.
- Effective Date: Date from which it is valid.
- Expiration date: Till when its valid
Maintaining Business Rules
Best way to maintain business rules is in X - Y Matrix. This Matrix creates a link between FR ID and UC ID. So anytime business analyst needs to update a business rule, it just have to go to the matrix rather than eah individual use case.
 |
| FR - UC Matrix |
If we talk about Agile methodology then UML Activity diagrams are the best way to communicate requirements. In the previous post we mentioned UML Use case diagrams as well.
So it makes sense to move to UML Diagrams.
No comments:
Post a Comment