In the previous post, I introduced BRs and their importance. In this post, I'll discuss how to identify BRs and how to describe them in SRS documents. Identifying the Inputs:
Identifying BRs primarily starts in the elicitation phase. When you interact with business users to gather information, pay close attention to the formulas and business rules they use.
For example, if you're gathering requirements from the sales department, the rules might be the formula for calculating sales KPIs for each salesperson or the formula for calculating revenue/sales for each sale.
Note: The information gathered in this step is still a business requirement, not yet a business rule.
Proposing Solutions: Once you have the requirements in the form of formulas and rules, the next step is to propose solutions for implementing these rules in the system.
These solutions are often represented as system functionalities. You can refer to this post about system function design.
Example:
The KPI calculation formula is applied when a sales order is finalized, and the sales amount is calculated for the salesperson according to the formula and updated in their corresponding KPI. --> The "Finalize Sales Order" function contains BRs related to calculating sales and updating KPIs.
The "View" KPI function needs to be authorized according to actual business practices, such as: Salespeople can view their own KPIs, sales managers can view the overall department KPI and individual KPIs of their team members.
All such solutions need to be "assigned" to a specific function, or more accurately, a specific use case of the software.
Detailed Description After the elicitation phase and having solutions in hand, the next step is to write a detailed description. In this case, I'll focus on describing use cases in the SRS document. The elements to be defined in a use case include:
Objective: The goal of the use case, e.g., placing an order on an e-commerce website.
Actor: The entities that can perform this use case. In this example, it would be the buyer.
Pre-condition: The preconditions for executing the use case. For example, the user must have an account and be logged in successfully.
Business rules: Rules to ensure the purchase use case is executed according to the e-commerce provider's business processes and that data is processed correctly.
Describing business rules includes:
Happy path or main flow of the business process: From the start of the use case to its completion. For example, purchasing starts when the user clicks the "Check-out" button in the shopping cart (searching, adding items to the cart are other use cases). Then, the system needs to process the customer's payment, create an order, and send information to the seller or shipping unit, etc.
Failure cases: Mainly from validation steps, such as checking if the item is in stock at the time of order, whether payment and shipping information is filled in correctly, etc. If there are errors, how to notify the user (e.g., with an error message).
Often, when describing use cases, people tend to focus more on the happy path and forget or overlook the description of failure cases.
Example with the purchase case above:
BRs related to display: Which screen is displayed after the user selects "Check-out"? What information is included on the screen?
BRs related to information verification (validation): Are any required fields left blank? Is any information in the wrong format? Are the items in stock at the time of order? If there are errors, display corresponding error messages. If there are no errors, proceed with payment processing.
BRs related to payment processing: The payment request for the order is transferred to a wallet, bank, or international payment gateway (Visa/Mastercard...). The system receives payment feedback from the third party and handles error reporting if the payment fails. Or, it proceeds with creating a new order if successful.
BRs related to creating a new order: Create an order with the information entered or selected by the user (such as shipping information, quantity, payment information...). Additionally, there's information automatically generated by the system, such as the order code (the BA must define the code generation rule after gathering and analyzing requirements) and the status of the newly created order (the status depends on the business's sales workflow). After the information is created, it's saved to the database, and the user is notified that the order was created successfully. Necessary emails or notifications are sent, and the newly created order is displayed for the customer to view.
This concludes the description for the purchase use case. Of course, the descriptions above need to be written according to the specific rules of each business.
Points to Note:
Use the 5W1H question framework during the analysis process to write BRs.
Always ask questions about the input/output of each step. For example, what are the inputs for placing an order? (Quantity, amount, shipping information, payment information...)
Pay attention to failure cases: What if the user doesn't do this? What if the information is wrong? What if this step fails?
Keep descriptions concise: Avoid writing long paragraphs (like what I've done above, which is more narrative). The example above can be rewritten for a specific BR as follows:
If [Shipping Address] = "", the system displays an error message "This is required information."
For each item in the order, the system checks the inventory quantity. If <inventory> < [Quantity]: The system displays the message "Item [item name] is out of stock, please choose again."
Arrange the order of business rules:
Prioritize arranging them sequentially according to the happy path flow.
Simple processing logic like screen display, checking for empty or incorrectly formatted information should be listed first.
More complex information related to business processes or integration with other systems should come later.
Prioritize based on BR dependencies, such as BR 1 must be completed before BR 2 can be executed. For example, in the order creation step: an order cannot be created if the order code and status haven't been generated. New order notifications or emails cannot be sent if the order hasn't been created.
These are the steps to describe BRs for use cases in BA SRS documents. I hope this post helps you in your work and minimizes errors in your documentation.
Hozzászólások