Loading in 2 Seconds...
Loading in 2 Seconds...
University of Palestine College of Information Technology Requirement engineering Chapter 9 Playing by business the Rules Ahmed Obaid Fawzy AL Taybe Waled Ayish Fariza EL Sharif Norurhan Abo hane. Outline: The Rules of the Business. classification schemes.
University of PalestineCollege of Information TechnologyRequirement engineering
Chapter 9Playing by business the RulesAhmed Obaid Fawzy AL TaybeWaled AyishFariza EL Sharif Norurhan Abo hane
The Rules of the Business.
Documenting Business Rules.
Business Rules and Requirements.
list of complex natural language rule statements.
Every business organization operates according to an extensive set of corporate policies, laws, and industry standards. Industries such as banking, aviation, and medical device manufacture must comply with volumes of government regulations.
Such controlling principles are collectively known as business rules.
Software applications often enforce these business rules. In other cases, business rules aren't enforced in software but are controlled through human enforcement of policies and procedures .
A business ruleis a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.
Unless you're building a system that is heavily business-rule driven, you don't need an elaborate methodology. Simply identify and document the rules that pertain to your system and link them to specific functional requirements.
Many different taxonomies: have been proposed for organizing business rules.
A sixth category is terms, defined words, phrases, and abbreviations that are important to the business
A glossary is a convenient place to define terms. Recording the business rules in a consistent way so that they add value to your software development efforts is more important than having heated arguments about how to classify each one. Let's look at the different kinds of business rules you might encounter.
Factsare simply statements that are true about the business, Often facts describe associations or relationships between important business terms. Facts are also calledinvariants,immutabletruths about data entities and their attributes.
Other business rules might refer to certain facts, but facts themselves don't usually translate directly into software functional requirements.
Facts about data entities that are important to the system might appear in data models that the analyst or database designer creates
Examples of facts are:
Constraints restrict the actions that the system or its users may perform. Some words and phrases that suggest someone is describing a constraint business rule are must, must not, may not, and only.
Examples of constraints are:
A rule that triggers some activity under specific conditions is an action enabler.
A person could perform the activity in a manual process. Alternatively, the rule might lead to specifying some software functionality that makes an application exhibit the correct behavior when the specified conditions are true.
The conditions that lead to the action could be complex combinations of true and false values for multiple individual conditions.
inference is a rule that establishes somenew knowledge based on the truth of certain conditions. An inference creates a new fact from other facts or from computations.
Sometimes called inferred knowledge.
Computers compute, so one class of business rules defines computations that are performed using specific mathematical formulas or algorithms. Many computations follow rules that are external to the enterprise, such as income ,tax withholding formulas.
Whereas action-enabling business rules lead to specific software functional requirements to enforce them, computational rules can normally serve as software requirements as they are stated.
Table (1.1): Represent Computational Business Rules
A single computationcould include many elements. The total price computation in the final example in the preceding list includes volume discount, sales tax, shipping charge, and insurance charge computations. That rule is complicated and hard to understand.
To correct this shortcoming:
Business rules can influence multiple applications, organizations should manage their business rules as enterprise -level not project -level- assets.
A simple business rules catalog will suffice initially. Large organizations or those whose business operations and information systems are heavily business-rule driven should establish a database of business rules.
Commercial rule-management tools become valuable if your rules catalog outgrows a word processor or spreadsheet solution or if you want to automate aspects of implementing the rules in your applications.
As you identify new rules while working on an application, add them to your catalog rather than embedding them in the documentation for that specific application or—worse—only in its code. Rules related to safety, security, finance, or regulatory compliance pose the highest risk if they are not managed and enforced appropriately.
Don't make your business rules catalog more complex than necessary. Use the simplest form of documenting business rules that ensures that your development teams will use them effectively .
Depending on the application, sometimes you invent business rules as you go along and sometimes you discover them during requirements discussions
Simply asking users:
Often the project stakeholders already know about business rules that will influence the application, and the development team must work within the boundaries that the rules define.
The types of questions the analyst can ask when workshop participants are discussing various issues and objects.
The analyst should document the business rules that come out of these elicitation discussions and ask the right people to confirm their correctness and to supply any missing information.
Business Rules and Requirements
After identifying and documenting business rules, determine which ones must be implemented in the software. Some rules will lead to use cases and hence to functional requirements that enforce.
Consider the following three rules:
If the expiration date for a chemical container has been reached, then notify the person who currently possesses that container.
A container of a chemical that can form explosive decomposition products is considered expired one year after its manufacture date.
Ethers can spontaneously form explosive peroxides.These rules serve as the origin for a use case called “Notify Chemical Owner of Expiration”.
You can define the links between a functional requirement and its parent business rules in the
following two ways:
There's another risk of keeping the rules separate from the functional requirements:
Rules that make sense in isolation might not be so sensible when viewed in an operational context with other requirements.
As with so many aspects of requirements engineering, there is no simple, perfect solution to managing business rules that works in all situations.