[alert type=”general”] This guest post by Adriana Beal is part of a series of contributions by business analysis professionals I respect, and whose work I follow. Adriana writes on a range of business analysis-related topics, and I have especially enjoyed her publications on business analysis performance measurement. Check out her site, Beal Projects for more of her work. Enjoy! – JB[/alert]
Many BAs I coach make the mistake of mixing software capabilities with business rules, employee procedures, and operational guidelines when documenting requirements for an information system or software application.
Here are a few real-life examples of things that I’ve seen being incorrectly listed as part of the requirements in software specification documents:
“Vendor activities (Check Stock, Ship Product) need to be completed before their due date/time.”
This statement is clearly not a software requirement. We are not describing an automatable procedure, as the system can’t “force” employees to complete their activities before the deadline. This needs to be treated as a job responsibility, rather than a software requirement, and can be a valuable source for discussion of potential additional requirements to help support the business objective. For example,
“Employees responsible for vendor activities (Check Stock, Ship Product) will see their pending tasks in a Work Queue, with a visual indication of approaching and missed deadlines.”
(This type of capability can help reduce the risk of employees missing their due dates, although it’s still the responsibility of each person to make sure their activities are completed on time.)
“Any uploaded material must be legally distributable.”
You may very well wish that users upload to the system only legally distributable material, but most likely won’t have the means to prevent illegal material from being uploaded.
Instead, to help the business achieve this objective, you might end up with a requirement like this:
“When a user attempts to upload content, the system will prompt him to confirm that the material is legally distributable before completing the action.”
(While it’s still the responsibility of the user to ensure the policy is followed, the system can help reduce the risk of non-compliance by providing a reminder and requiring user confirmation.)
“Consultants in a client assignment are required to work 40 hours a week.”
Well, that may be your company’s expectation or policy, but again, in practice your software can’t enforce that rule. And what if a consultant gets sick, or has to travel to take care of personal business? Now, a requirement like this might make sense for a time tracking system:
“The system will require consultants in a client assignment to enter at least 40 hours in their weekly timesheet before being allowed to submit it, providing the appropriate codes for client work, sick leave, unpaid leave, vacation, and training.”
(Now you are creating a valid constraint in the system to ensure that consultants don’t submit less than 40 hours while reporting week hours, so HR can correctly compute billable and non-billable time and the payable amount for each consultant.)
* * *
Business policies, rules, procedures and protocols are criteria that guide business activity and support operational decision-making in organizations. As seen above, they are a great source of potential requirements for IT solutions to business problems, but typically can’t be treated software requirements themselves. Knowing how to derive and propose the right requirements based on policies and rules is a competence that every business analyst should develop to increase his/her contribution to software projects.
One great way to dig out business rules is to walk through a process diagram. Decision points (split paths) and anything that prevents a process from moving forward is usually a business rule.
Hi, Angelo,
I’m a big fan of visual representations, and I’m glad you mentioned process diagrams as a good way to surface business rules. Indeed, decision points in a process flow are a good indication of the existence of a business rule. To reuse one of my examples, if you had a diagram for “file upload” showing a decision diamond “user confirmed the material is legally distributable? Yes / No”, it would be easy to derive from it the rule “Any uploaded material must be legally distributable.”
Thanks for contributing to the conversation!
Great article. I really like the examples and the comments about how decision points in process flows can indicate business rules. That’s a great point.
Yep, agree
I think the problem arises in many cases due to the use of old-school documentation formats where we isolate these items.
Use Cases, or User Stories are great way to capture all that is needed, without being overly academic about it, due to their holistic and goal focus.
And, as was said above, visual modelling often helps to separate these items out as well.
That’s a nice article regarding business rules. Thanks.
Hi Adriana Beal,
This Business Rules article is very nice.
http://www.bacourse.com
Sometimes rules can be reverse engineered when they are undocumented and/or the knowledge has gone with the former employees who possessed it. We were able to get quite a few rules by looking at error and warning messages that systems throw when evaluating user inputs (e.g., customer applications for insurance). They often throw those messages because a rule has been violated.
Thanks everyone for your comments.
@Mark: indeed, that’s a common way to recover undocumented business rules, to reverse engineer from error and warning messages (as well as conditional statements in the code). It goes without saying that a much better practice is to have a repository of the rules that is independent of the system you’re using (so that if the system is replaced, you don’t lose this knowledge). This problem of undocumented rules is only going to get worse as companies move more and more to a cloud/SaaS environment, because if you’re not careful critical knowledge can be lost when you have to change providers.
This article has given me a greater depth of understanding on the role of a BA, thanks!
Hi,
Your post is very nice. Thanks.
Regards,
Sudha J
Research Analyst
Fhyzics Business Consultants Pvt. Ltd.
http://bacourse.com/