Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
31 Cards in this Set
- Front
- Back
What was discussed in Session 3?
|
Business Needs , Stakeholder List Roles and Responsibilities..
|
|
What were the key learning objectives for session 3?
|
Learning Objectives
Getting stakeholder and solution requirements stated by Approaching Business Rules Analysis with confidence by making use of document analysis using mind-mapping to elicit them, and verifying them using decision trees and decision tables Clarifying stated requirements by making use of techniques such as data dictionary, data modeling, and the possibilities table |
|
What is the definition of Business Rules?
|
To define rules that govern decisions in an organization and that define, constrain, or enable organizational operation. (BABOK guide)
Business rules should be: Stated in appropriate terminology Documented independently of how they will be enforced. Stated at the detailed level. Separated from processes that rule support or constrains. Maintainable. |
|
What is the Hierarchy of business rules?
|
A business Policy is a non-actionable directive that supports a business goal.
E.g. “XYZ company A business Rule is a specific, actionable, testable directive that is under the control of an organization and that supports a business policy. E.g. “product descriptions must state the % of recycled material included in the product “. |
|
What are the Business Rules Elements?
|
Operative Rules: rules to be used for enforcing policy matters. A guide for people working in the organization. e.g. “Personal accounts with a balance of $0 which have had no customer activity for a twelve months, will be closed”.
Structural Rules: rules to determine if something is or is not true. Describe categorizations that may change over time. E.g. “In order for an account to have no customer activity for 12 months, the activity log for “last12months” must give a zero count. |
|
What are some key terms for Business Rules Overview?
|
Use a defined glossary of terms and understanding of the relationships between them.
Make no dependencies on other information. Do not include any assumptions. Use tools like Decision Tables, Data Dictionary and Data Modeling to document Business Rules. |
|
What is a practical approach for Business Rules?
|
Review, Group, Consult, Categorize, and Check.
|
|
What are some of the steps for Business Rules testing and verification?
|
You need to verify the adequacy of business rule definitions before enforcing.
Create decision table and decision tree Try few different scenarios: Check for positive and negative cases Document the outcomes Ask a SME or an expert to verify your outcomes You may seek legal advice in some cases Make adjustments if necessary |
|
What is a Decision table?
|
A table created to link observable conditions ( its raining) to necessary actions ( take an umbrella)
Very useful in Business Analysis for capturing and clarifying business rules that apply in the business area Using a decision table enables the BA to ensure that all condition states( the forecast says it will rain) and all action states ( put umbrella in car) are clearly defined. |
|
How many quadrants does a decision table have?
|
A decision table has 4 quadrants:
Conditions Condition alternatives Actions Action entries |
|
Decision Table Usage?
|
You can use Decision Tables in:
Business Analysis Programming Testing Hardware Design Decision Tables are also a way to represent Business Rules ! |
|
Creating Decision Tables
|
What questions need to be answered before you can determine what to do ?
What are the different values each of these can take? What are all the possible outcomes of this process ? What actions could the business take? Calculate numbers of distinct scenarios and assign a column for each Complete entries so that each column shows a distinct set of values Document each required action with an “X” in the appropriate action cell |
|
What is Document Analysis?
|
The systematic examination of existing documentation to discover information, issues, or to understand policies, procedures and business rules.
|
|
Why is Document analysis an important technique for business analysis?
|
Provides access to prior knowledge on a wide variety of relevant areas that have already been documented.
Prompts for questions that the BA needs to find answers to. Gives clues to requirements which appear as either explicit conditions that must be met or implicitly as desired outcomes in plans, policies, procedures and forms. |
|
Features and Benefits of document analysis?
|
Especially useful
Look carefully at the dates Complements other elicitation techniques Takes Time Especially useful: In situations where the project involves an update to an existing solution and the Subject Matter Experts for the existing solutions are no longer available to the project. Look carefully at the dates. Regardless of the type of documents studied, such as business plans, market studies, RFP, training guides, current guidelines and procedures, existing system specifications, it is important to keep in mind that they must be as most up to date as possible. Check the dates and ask if there were more recent versions created, even if these were drafts. Complements other elicitation techniques. Findings from this process can validate requirements obtained from other elicitation techniques. Takes time. Studies of such vast amount of materials are likely to cost Business Analysts a lot of their valuable time. |
|
What are some of the document analysis steps?
|
1) Prepare
2) Conduct 3) Follow Up Prepare. Catalogue the existing system and business documentation. Ask stakeholders “ What documents would be useful for me to review to better understand the business goals, process and current systems in this area, and where can I get hold of a copy ?”. Go quickly through all sources of information available to determine what is relevant and suitable to be reviewed in detail. Conduct. Review the materials and identify and record relevant business details. These details should be documented along with questions intended for subject matter experts. Follow-up. Confirm significant details with subject matter experts or from other sources, where these are not available. |
|
What are some document sources?
|
Training Manuals
Regulations Maintenance guides Job Aids System documentation Manual Forms Products Catalogues and other relevant Customer Information |
|
What are some other things we can do to clarify requirements?
|
1) Possibilities Table
2) Data Dictionary and glossary 3) Data modeling During elicitation we may collect statements and document them at “face value”. We need to clarify them and ensure they are as complete as we can make them. Several techniques exist to assist us We can analyze stated requirements to see if they would be more usefully expressed in more general or more specific terms. This is the Possibilities Table. We can create an organized and cross-referenced repository of terms to ensure the terms used are correct. This is the Data Dictionary and Glossary. We can define the interrelationships between entities. This is accomplished by Data Modeling. |
|
How sift stakeholder input (possibilities table)
|
Sifting Stakeholder Input
Any given statement from a stakeholder is likely to be in the "right ballpark" but may not be "on base". Aspects of it may be either more specific than is strictly necessary of not specific enough. For instance there may be additional factors and exceptions that need to be stated. One way to "process" each statement is to break it down into parts and systematically test each part using a technique known as a Possibilities Table (aka an abstraction table). |
|
Possibilities Table-Example of Initial Stakeholder Statement
|
"An email must be sent to the assigned service provider as soon as a service ticket is raised by a user".
Can we see aspects that could be too limiting or too vague? If so analyze ! |
|
Glossary - Keeps everyone on the "same page"
|
Glossary
|
|
What is the definition of data dictionary and glossary?
|
Definition:
Centralized repository of information about data. A file that defines the basic organization of a database. A database that contains definitions of all data items defined during analysis. A document or system that characterizes the data content of a system. A tool that provides metadata or information about data. A data dictionary describes the definitions, attributes, and context (e.g. proprietorship, business rules) of data elements within a data set. |
|
More on Data Dictionary and Glossary.
|
A data dictionary or glossary defines key terms and data relevant to a business domain
For example : Client, Customer, Patient- Does it matter ? Which is which ? A person buying products or services from a business. A person retaining a professional to protect their interests A person receiving or registered to receive medical treatment |
|
What is the purpose and usage of data dictionaries / glossary?
|
To define key terms and data relevant to a business domain.
To give you everything you would want to know about the project. To formally identify and define all terminology used by the organization within the scope of analysis To ensure all stakeholders are in agreement on the format and content of relevant information. |
|
What are some types of data models?
|
1) Entity-relationship model or Class Diagram
2) Geographic data model 3) Generic data model 4) Semantic data model |
|
What is an Entity-Relationship Model?
|
Relationships between Customers, Orders and Order Items
Also shows Cardinality- the number of occurrences of one entity that are linked to a second entity May indicate a Primary Key- which uniquely identifies an occurrence of each entity, is generated by an internal ( customer #) or external system ( e.g. Postcode) |
|
What is cardinality in ER Diagrams?
|
Types : One-to-One, One-to-Many, Many-to-Many
Legend : 0, 1 or < (Many) on the line indicates the allowable range of occurences Again read left to right See previous diagram “ One customer may have between Zero & Many orders” “One order may have between One & Many order items” ( Interpretation : A customer has an account and so may not have an order in system right now, but if they do have a order its because they are purchasing one or more items currently) |
|
ERD Insurance Example
|
Interpretation for stakeholder
Each underwriter approves zero or more amendments Each amendment is approved by one underwriter Is anything missing from this diagram ? If so, what ? |
|
Creating an Entity-Relationship Model
|
Identify Entities (from Glossary) that have more than one attribute (things to track about them)
Write each entity in capitals (name it in the singular) Draw a box around each entity. List candidate attributes for each entity ( look at output documents) Define a Primary Key for each Entity ( identifier that distinguishes instances of this entity from other occurrences of same entity). Identify relationships among entities (see next page) |
|
How to find the relationships?
|
Look up on page 53.
Identify where relationships exist among entities ( Can <Entity Name 1> exist without <Entry Name 2 > ? . If yes, there is no relationship. If no, then draw a connecting line. Analyze the nature of the linkage. What is the verb that links ? “Customer places order” Write it above the line. Then write the inverse relationship in the passive voice and put below line. “Order is placed by Customer”. Determine and map the cardinality ( Can an occurrence of Entity A be related to one or more than one occurrence of Entity B ? And vice-versa). Review one-to-one relationships carefully as experts say these are rare in practice. Adopt a Data Model with built-in relationships. In some cases there is a quicker way to identify the relationships because they are defined by the Glossary, are pre-determined or follow physical laws. |
|
Class diagram (UML)
|
Insurance example, page 59
|