Project Requirements Excellence – Part 5
Requirement Business rules
Whether implemented in a technology solution or not, business rules define the way the business works. They provide a model of how a business runs and manages its enterprise, describing the government’s framework for the process is, data, and actors within the business, and defines the business logic that ties together the data, process is, and agents/actors.
Business roles are defined control or constraint conditions under which an actor may, or may not, perform or complete process or successfully view or transform data.
Overall, business rules provide for different outcomes or results. Positive business rules get permission or allow something to happen, such as “employee is given one additional vacation day credit after two years of employment” while negative rules restrict the actions or data values, as in “check number must be greater than 99 and less than 9,999,999.
The solution should not allow business leaders, processes, policies, or data to be undermined or compromised by allowing actions or data changes contrary to business operating procedures, regulatory policies, laws, or any other relevant stakeholder rule.
Requirements – The challenge of business rules
Writing excellent requirements, gets most challenging when you are defining business roles because business stakeholders frequently do not realize the circumstances under which they make decisions or allowances.
In fact, stakeholders may not even recognize that certain policies exist if they have not consciously thought about them.
Identifying and isolating the decision factors in the business rules that govern the work or the data is considered an Art form.
A whole segment of the business analysis industry – including many specialists and technology solutions – devotes itself solely to the art of identifying and managing business roles, decision models, and decision automation.
As part of analyzing business rules, you must as a minimum be able to write down its description or outcome at a high level. You will then work with your stakeholders, to figure out all the exceptions to that rule because those exceptions usually turn out to be the primary business factors and decision criteria.
Work can be done or situation is resolved in many ways, but in a business environment, the decision about whether something will be carried out depends on different decision criteria or factors.
Evaluation factors such as data values, security rights, order of events, or timing of actions can all play a part in determining whether something should or will be allowed to occur within the system or solution.
As an example here, a business role may be “benefits enrollment is allowed only 90 days after hire date or during the open enrollment period”.
But to identify the outcomes and exceptions, you really need to dig beneath the surface and asked the stakeholders questions like:
- “What if the employee is a rehire working here for a second time?”
- “Which hire date gets used in the evaluation of this rule?”
- “Does the rule mean 90 days off to the latest hire date?”
- “What happens on day 91?”
Requirements – Use of cardinality for business rules
Business rules also have cardinality. The business must decide whether roles are optional or mandatory.
Optional roles allow actors to perform the action will transform the data despite a suggestion to the contrary. The showroom sales through warnings on what is called “call ask the user first prompts”.
You have probably seen one of these while using her and Software Solutions – after requesting an action or trying to update information that goes against what the system is supposed to do, you may have been done something like “are you sure?”, or “you are not supposed to do that – do you want to do it anyway?”.
If the actor is not a human who can immediately respond to warnings but rather is another system, warnings or optional roles either will be suppressed and not seen or will be documented on a report or exception log that tracks its success or failure of the interface transactions.
In that case, you see a list of messages raising concerns about the data transmissions or changes, and suggesting that the specific transactions be reviewed or issues resolved.
Mandatory rules create errors for the actor, who experiences a block or pause in the workflow such as a message or window that stops the activity until the actor response to the error and resolves the issue.
A familiar roles-based error is “wrong password, try again”. The accompanying mandatory rule may be “user must provide a valid username and password for access”.
In system interfaces, or batch jobs which are automated, unattended data transformations or information transfers, errors may result in data not being processed or transmitted at all.
In such a case, air as are commonly recorded and reported through the exception/Error log for later review and resolution.