[ Pobierz całość w formacie PDF ]
.Manymore increments can happen in parallel and each can have many more interactions.Figure 5.1: Project plan for incremental deliverySummaryBy now you may be aware of the subtle but important benefits that are achievable whenyou manage business rules as a separate component.For example:A business user should be able to query a rule repository in many ways.Therepository can produce a history of the rule, an explanation of the businessobjectives it aims to serve.A business rules approach puts the business people at the helm of thebusiness and also at the helm of systems development.The businesspeople steer the behavior of resulting systems by supplying, adding,changing, or archiving rules so as to effect business change.140 Business change, then, ceases to be disruptive to systems delivery and to thebusiness itself.Instead, business change becomes a proactive, strategic,business weapon.The business rule becomes the fuel to energize thebusiness change.Pay special attention to the tasks in the plans above marked with asterisks because it iswithin these tasks that change in philosophy, focus, techniques, and even productscome into play.It is within these tasks that very small changes take place.These arethe changes that will make all the difference in the world to your business organization.These are the changes that separate, trace, externalize, and position for change thepolicies and rules of the business.so that the business can become what it wants tobecome.so that information technology becomes a strategic enabler the weapon ofchange and no longer a barrier to future possibilities.141 Part III: DiscoveryChapter ListChapter 6: Discovering Initial RequirementsChapter 7: Discovering Rules and DataChapter 8: Discovering Rules through Facilitated Sessions142 Chapter 6: Discovering Initial RequirementsOverviewYou may have arrived at the discovery phase from various previous points.There mayhave been a prior business process engineering or reengineering effort.Or you mayhave completed the scoping steps outlined in Chapter 4.Regardless, the discoveryphase begins when there is a defined project scope to develop a target informationsystem, a business commitment to build the information system, a detailed plan for howto proceed, and a desire to develop the information system with a business rulesapproach.Figure 6.1 reminds you of where the discovery phase fits with respect to the otherphases in the methodology.Note that the discovery phase addresses the discovery ofrequirements in four tracks: process, data, technology, and rules.This chapter focusesmostly on the discovery of requirements in the process track as a starting point.Because the discovery process in this book places new emphasis on the rules track,you will want to address the concepts in Chapter 15 for managing rules.Figure 6.1: Business rule systems methodology phases.What Is the Discovery of Initial Requirements?In this book, the discovery of initial requirements means gaining a preliminaryunderstanding of four aspects: potential process flow (most likely through documentinguse-case descriptions), instances for testing purposes (through collecting concretescenarios), intellectual decision-making behind the process (through capture ofdecisions), and the potential for sharing information (through developing a conceptualmodel).For tutorial purposes, and to provide a new emphasis on rules, this book separates thediscovery of process-oriented (who, when, where, and how) requirements from data(what) and rules (why).In reality, you may discover them all at once, most likely overseveral iterations.143 How Is Discovery of Initial Requirements Different for a Business RulesApproach?Most of you will notice that the first two steps in this chapter (create use-casedescriptions and identify concrete scenarios) are similar to how you would begindiscovering requirements for most object-oriented and even non-object-orienteddevelopment efforts.The third step, perhaps may seem new to you.It represents thediscovery of decisions, rather than moving directly to an initial discovery of objects or ofsequences of responsibilities among objects.This shift in emphasis occurs because ofsix subtle differences in discovering initial requirements for a business rules approachoutlined in Table 3.1:Separating rules by decomposing business events into business decisions.Tracing rules by correlating decisions to business context (organizationalpolicies, strategies, objectives, goals).Tracing rules by associating decisions and rules with use cases.Externalizing rules by identifying concrete scenarios.Positioning rules for change by correlating rules to information referenced andcreated.Positioning rules for change by avoiding premature commitment to executionsequence.Let s look at each of these differences.The first, most unique difference is the decomposition of a business event into a set ofactivities, but focusing first on those activities that are decision-rich.The seconddifference is that you make sure the decisions occur in concert with business context,such as organizational policies, strategies, and objectives.Because you perceive aprocess primarily as a series of decisions, you focus early on policies (if any and ifknown) for each decision.After all, if there is a decision to be made about something,there probably is a policy to guide the decision (somewhere).Otherwise, why would theorganization bother making the decision? Further, if you have done your scoping anddiscovery activities with diligence, the policy should provide a lot of useful informationsuch as: What does it intend for the result to be? Is it a mandatory policy or a guidelineonly? Who is most responsible for the policy? Over what jurisdiction does it apply? And,most important of all, what is its rationale? In other words, you are rounding out themotivation and intelligence behind the decision to make sure it has maximum businessvalue.The third difference is that you will associate rules or decisions to those use cases thatrely on them.You will learn that decisions and rules may be shared across use cases,much like information may be shared.Next is the fourth difference which is the identification of a more complete set ofconcrete use cases to be sure that every rule can be tested.This brings you to the fifth difference, which is avoidance of premature commitment toexecution sequence.That is, you do not obsess over sequence of activities or tasks atthis time.You want to understand the decisions (intelligence) behind the event first, andonly later on work out how communications happen among objects to carry out thatintelligence.The sixth difference is a focus on the information referenced and knowledge created bythe business event, or actually on the decisions employed by a business event.Later, during the analysis phase, you will determine which of those decisions (andunderlying rules) are to be shared across organizational and application boundaries.144 That s because the rules are the thinking behind the business event [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.Manymore increments can happen in parallel and each can have many more interactions.Figure 5.1: Project plan for incremental deliverySummaryBy now you may be aware of the subtle but important benefits that are achievable whenyou manage business rules as a separate component.For example:A business user should be able to query a rule repository in many ways.Therepository can produce a history of the rule, an explanation of the businessobjectives it aims to serve.A business rules approach puts the business people at the helm of thebusiness and also at the helm of systems development.The businesspeople steer the behavior of resulting systems by supplying, adding,changing, or archiving rules so as to effect business change.140 Business change, then, ceases to be disruptive to systems delivery and to thebusiness itself.Instead, business change becomes a proactive, strategic,business weapon.The business rule becomes the fuel to energize thebusiness change.Pay special attention to the tasks in the plans above marked with asterisks because it iswithin these tasks that change in philosophy, focus, techniques, and even productscome into play.It is within these tasks that very small changes take place.These arethe changes that will make all the difference in the world to your business organization.These are the changes that separate, trace, externalize, and position for change thepolicies and rules of the business.so that the business can become what it wants tobecome.so that information technology becomes a strategic enabler the weapon ofchange and no longer a barrier to future possibilities.141 Part III: DiscoveryChapter ListChapter 6: Discovering Initial RequirementsChapter 7: Discovering Rules and DataChapter 8: Discovering Rules through Facilitated Sessions142 Chapter 6: Discovering Initial RequirementsOverviewYou may have arrived at the discovery phase from various previous points.There mayhave been a prior business process engineering or reengineering effort.Or you mayhave completed the scoping steps outlined in Chapter 4.Regardless, the discoveryphase begins when there is a defined project scope to develop a target informationsystem, a business commitment to build the information system, a detailed plan for howto proceed, and a desire to develop the information system with a business rulesapproach.Figure 6.1 reminds you of where the discovery phase fits with respect to the otherphases in the methodology.Note that the discovery phase addresses the discovery ofrequirements in four tracks: process, data, technology, and rules.This chapter focusesmostly on the discovery of requirements in the process track as a starting point.Because the discovery process in this book places new emphasis on the rules track,you will want to address the concepts in Chapter 15 for managing rules.Figure 6.1: Business rule systems methodology phases.What Is the Discovery of Initial Requirements?In this book, the discovery of initial requirements means gaining a preliminaryunderstanding of four aspects: potential process flow (most likely through documentinguse-case descriptions), instances for testing purposes (through collecting concretescenarios), intellectual decision-making behind the process (through capture ofdecisions), and the potential for sharing information (through developing a conceptualmodel).For tutorial purposes, and to provide a new emphasis on rules, this book separates thediscovery of process-oriented (who, when, where, and how) requirements from data(what) and rules (why).In reality, you may discover them all at once, most likely overseveral iterations.143 How Is Discovery of Initial Requirements Different for a Business RulesApproach?Most of you will notice that the first two steps in this chapter (create use-casedescriptions and identify concrete scenarios) are similar to how you would begindiscovering requirements for most object-oriented and even non-object-orienteddevelopment efforts.The third step, perhaps may seem new to you.It represents thediscovery of decisions, rather than moving directly to an initial discovery of objects or ofsequences of responsibilities among objects.This shift in emphasis occurs because ofsix subtle differences in discovering initial requirements for a business rules approachoutlined in Table 3.1:Separating rules by decomposing business events into business decisions.Tracing rules by correlating decisions to business context (organizationalpolicies, strategies, objectives, goals).Tracing rules by associating decisions and rules with use cases.Externalizing rules by identifying concrete scenarios.Positioning rules for change by correlating rules to information referenced andcreated.Positioning rules for change by avoiding premature commitment to executionsequence.Let s look at each of these differences.The first, most unique difference is the decomposition of a business event into a set ofactivities, but focusing first on those activities that are decision-rich.The seconddifference is that you make sure the decisions occur in concert with business context,such as organizational policies, strategies, and objectives.Because you perceive aprocess primarily as a series of decisions, you focus early on policies (if any and ifknown) for each decision.After all, if there is a decision to be made about something,there probably is a policy to guide the decision (somewhere).Otherwise, why would theorganization bother making the decision? Further, if you have done your scoping anddiscovery activities with diligence, the policy should provide a lot of useful informationsuch as: What does it intend for the result to be? Is it a mandatory policy or a guidelineonly? Who is most responsible for the policy? Over what jurisdiction does it apply? And,most important of all, what is its rationale? In other words, you are rounding out themotivation and intelligence behind the decision to make sure it has maximum businessvalue.The third difference is that you will associate rules or decisions to those use cases thatrely on them.You will learn that decisions and rules may be shared across use cases,much like information may be shared.Next is the fourth difference which is the identification of a more complete set ofconcrete use cases to be sure that every rule can be tested.This brings you to the fifth difference, which is avoidance of premature commitment toexecution sequence.That is, you do not obsess over sequence of activities or tasks atthis time.You want to understand the decisions (intelligence) behind the event first, andonly later on work out how communications happen among objects to carry out thatintelligence.The sixth difference is a focus on the information referenced and knowledge created bythe business event, or actually on the decisions employed by a business event.Later, during the analysis phase, you will determine which of those decisions (andunderlying rules) are to be shared across organizational and application boundaries.144 That s because the rules are the thinking behind the business event [ Pobierz całość w formacie PDF ]