University of Palestine College of Information Technology Requirement engineering

University of PalestineCollege of Information TechnologyRequirement engineering Chapter 9Playing by business the RulesAhmed Obaid Fawzy AL TaybeWaled AyishFariza EL Sharif Norurhan Abo hane

Outline: The Rules of the Business. classification schemes. Facts Constraints Action Enablers Inferences Computations Documenting Business Rules. Business Rules and Requirements. list of complex natural language rule statements.

Introduction 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.

Introduction 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 .

The Rules of the Business 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.

classification schemes 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

classification schemes 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.

Facts 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 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 Examples of facts are: • Every chemical container has a unique bar code identifier. • Every order must have a shipping charge. • Each line item in an order represents a specific combination of chemical, grade, container size, and number of containers. • Sales tax is not computed on shipping charges.

Constraints 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 borrower who is less than 18 years old must have a parent or a legal guardian as cosigner on the loan.

Examples of constraints • A user may request a chemical on the Level 1 hazard list only if he has had hazardous-chemical training within the past 12 months. • All software applications must comply with government regulations for usage by visually impaired persons • Commercial airline flight crews must receive at least eight hours of continuous rest in every 24-hour period.

Action Enablers 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.

some examples of action-enabling business rules • If the chemical stockroom has containers of a requested chemical in stock, then offer existing containers to the requester. • If the expiration date for a chemical container has been reached, then notify the person who currently possesses that container. • On the last day of a calendar quarter, generate the mandated OSHA and EPA reports on chemical handling and disposal for that quarter. • If the customer ordered a book by an author who has written multiple books, then offer the author's other books to the customer before accepting the order.

Inferences 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.

Examples of inferences • If a payment is not received within 30 calendar days of the date it is due, then the account is delinquent. • If the vendor cannot ship an ordered item within five days of receiving the order, then the item is back ordered. • A container of a chemical that can form explosive decomposition products is considered expired one year after its manufacture date. • Chemicals with an LD50 toxicity lower than 5 mg/kg in mice are considered hazardous.

Computations 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.

Example compaction Table (1.1): Represent Computational Business Rules

list of complex natural language rule statements 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: • Write your business rules at the atomic level, rather than combining many details into a single rule. • A complex rule can point back to the individual rules upon which it relies. • This keeps your rules short and simple. It also facilitates reusing the rules and combining them in various ways.

list include the discount rules • If the delivery address is in a state that has a sales tax, then the state sales tax is computed on the total discounted price of the items ordered. • If the delivery address is in a county that has a sales tax, then the county sales tax is computed on the total discounted price of the items ordered. • The insurance charge is 1 percent of the total discounted price of the items ordered. • Sales tax is not computed on shipping charges. • Sales tax is not computed on insurance charges.

Documenting Business Rules 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.

Documenting Business Rules 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. • Trap: 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 .

Business Rules and Requirements Depending on the application, sometimes you invent business rules as you go along and sometimes you discover them during requirements discussions Simply asking users: • What are your business rules? doesn't get you very far, just as asking . • What do you want? doesn't help much when eliciting user requirements . 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.

Business Rules and Requirements 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.

Figure 1.2: Discovering business rules by asking questions from different perspectives. Business Rules and Requirements

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: • Rule #1 (action enabler): If the expiration date for a chemical container has been reached, then notify the person who currently possesses that container.

Business Rules and Requirements • Rule #2 (inference): A container of a chemical that can form explosive decomposition products is considered expired one year after its manufacture date. • Rule #3 (fact) : Ethers can spontaneously form explosive peroxides.These rules serve as the origin for a use case called “Notify Chemical Owner of Expiration”.

Business Rules and Requirements You can define the links between a functional requirement and its parent business rules in the following two ways: • Use a requirement attribute called "Origin" and indicate the rules as the origin of the functional requirement. • Define traceability links between a functional requirement and the pertinent business rules in the requirements traceability matrix.

Business Rules and Requirements • To prevent redundancy, don't duplicate rules from your business rules catalog in the SRS. Instead, the SRS should refer back to specific rules as the source of, say, algorithms for income tax withholding. • This approach provides several advantages: • It obviates the need to change both the business rule and the corresponding functional requirements if the rule changes. • It keeps the SRS current with rule changes because the SRS simply refers to the master copy of the rule. • .

Business Rules and Requirements • It facilitates reusing the same rule in several places in the SRS and across multiple projects without risking an inconsistency, because the rules are not buried in the documentation for any single application. • A developer reading the SRS will need to follow the cross-reference link to access the rule details. This is the trade-off that results when you elect not to duplicate information. 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.

University of Palestine College of Information Technology Requirement engineering