Have All Business Use Cases Been Discovered?
| The strategy described in this book shows you how to partition the work according to the business events that affect it. For each business event, you then determine the work's responsethe business use caseand decide how much of that response will be carried out by the productthe product use case. You gather the requirements one product use case at a time. This strategy is effective, providing you discover all of the business events. Missing business events must, inevitably, result in missing requirements. But how do you know whether you have discovered all the business events? The procedure for making this determination uses the outputs of your requirements process and system modeling. In other words, you do not have to produce more stuff, just make more use of what you have.
You do not have to produce more stuff to do the review, just make more use of what you have. Figure 14.2 illustrates the procedure for confirming the completeness of your list of business events. Follow along the model of this procedure as we describe its activities. Figure 14.2.The procedure for determining all business events have been found. The process is iterative, going through all activities until the Identify business events and non-events activity fails to discover any new ones. At this stage of the requirements process, you should have done most of these things. 1. Define the ScopeThe scope we are concerned with here is the scope of the work to be studied. In Chapter 3, Project Blastoff, we built a context model to show the scope of the IceBreaker work. To refresh your memory, this model is reproduced in Figure 14.3. The context model is mainly completed during the blastoff activity, then refined further as requirements analysis progresses. The review process we are describing here questions the completeness of your context diagram and where necessary, might bring about updates to it. Figure 14.3.The context diagram of the work shows the data entering and leaving the scope of the work. These data transfers are referred to as boundary data flows. We use these flows to determine the business events. 2. Identify Business Events and Non-EventsDuring the blastoff or at the beginning of trawling, you determined the business events by studying the boundary data flows on the context diagram. If an external business event happens, the adjacent system sends a data flow to the work to elicit a response from it. Thus each incoming boundary data flow indicates the potential for an external business event. The outgoing flows are either the output of the response to an external business event (the work responds by processing the incoming flow and produces the outgoing flow) or the result of a time-triggered event (such as reporting, sending out letters or alerts, and so on). In other words, each flow on the context model is some how connected to a business event.
The output of this activity is a list of business events, like that shown in Table 14.1 for the IceBreaker work.
Non-Events Once you have linked each of the boundary data flows to a business event, it is time to look for the non-events. The term "non-events" is a play on words. Non-events are events that happen if another event does not happen. For example, two non-events appear in Table 14.1. Event 9 is called "Truck treats a road." But what happens if the truck does not treat the road? This is a "non-event." It shows up as event 11, "Time to monitor road de-icing"the work checks whether the roads have been treated as directed and, if they have not, issues a reminder. In many businesses there is a business event called "Customer pays invoice"a common enough event. But what happens if the customer does not pay the invoice? The corresponding "non-event" is "Time to send reminder notice to nonpayers." Go through your own list of business events and ask, "What happens if this event does not happen?" Not all business events have a non-event, but checking the list for their existence may help you to discover some of the missing events. Add any new events discovered through this exercise to the list of business events, and update the context model with the appropriate flows. Continue searching the list of existing events for more non-events, but don't be overly concerned if you don't find one for every event. Sometimes the answer to the question, "What happens if this event does not happen?" is "Nothing." 3. Model the Business Use CaseThis step is not part of the requirements review, but something you have already done. As part of the requirements investigation, you will have built models or scenarios to help you and your stakeholders understand the desired response to the business event. Given that scenarios are the most commonly used models, we show a scenario in the schematic of the review process in Figure 14.2. However, the precise type of model you use is less important than the fact that you build models at all. A satisfactory model helps you understand and communicate the functionality and data for the business use case.
4. Define the Business DataThe next part of the review process is a step you might have already done: building a model of the stored data needed by the work that you are studying. You can use a class diagram, an entity relationship model, a relational model, or whichever data-modeling notation you prefer. As long as it shows classes, entities, or tables, and the associations or relationships between them, it will suffice. This data model is progressively confirmed and updated as a result of your requirements investigation. If building this kind of model is beyond your normal skill set, ask one of the database people to do it for you. They will have to build such a model at some stage; they may as well do it now, when it can serve more purposes than just aiding the logical database design. However, you must insist the database person builds a model of the business data, and does not start designing a database. They are two different things. Figure 14.4 shows a sample model of the data used by the IceBreaker work. Figure 14.4.This model shows the stored data used to predict and schedule the de-icing of roads. It uses UML class model notation. An alternative way of describing the business's stored data is to simply list the classes of data used by the business. Data classes (also called "entities") are the subject matter of stored data. In other words, they are the things that we store data about. You can think of a class as a collection of data elements (their correct name is "attributes") for something that is important to the business. The "something" can be real, such as a customer or a product you sell; or it can be abstract, such as an account, a contract, or an invoice. The important thing to note is that the class does not have an alphanumeric value. For example, an account has no alphanumeric value. The account number has such a value, but the account number is an attribute of the account class, not the account itself. Thus classes are things that have identifiers attached to them: Books have an ISBN to identify them; credit cards have a card number. Do not agonize too long over identifying the data classes. You should do as well as you can without spending the rest of the month on it. Some heuristics are generally helpful in identifying classes by defining their properties:
You can also find the classes from your context modelthe diagram that shows the data flowing into and out of work. In general, the stored data used by the work comes in via data flows and leaves via other data flows. Think about it this way: If there is data inside the work, there must be some flow of data to bring it there. That means you can dissect the data flows found in the context model and look at their attributes. Ask questions about them: "What is this attribute describing?" or "What is the subject of this data?" These subjects are your classes. Analyze all flows, both inward and outward, in the context model. You are looking for "things" that conform to the properties of classes listed earlier. When you have analyzed all of the flows, you have most likely identified all of the business data classes. Now we get to the fun part. 5. CRUD CheckEach class of data (check these on your class model) must be Created and Referenced. Some are also Updated and/or Deleted. You build a CRUD table, such as the one shown in Table 14.2, to determine whether every class has all the appropriate actions performed on it.
If a class is referenced without first being created, it means the creation event is missing. If a class is created without being referenced, then either an event is missing or there is superfluous data. Some classes (but not all) are updated and/or deleted; of course, for this to happen they must have been created. Holes in the CRUD table raise questions about missing business events. For example, the classes Depot and District show no creating business event. Thus the context is incomplete: It does not have the incoming flows to create these classes of stored data. When you find this situation, you must revisit your stakeholders to find out more about these missing business events. When you determine what they are, add them to the event list, update the CRUD table, and continue the process. The "Delete" column of the CRUD table shows classes that are deleted for business policy reasons only. This is not the same as archiving or cleaning up the database. For example, if a Depot were to be taken out of service, then it is essentially deleted. However, a Forecast is never deletedthere is no essential business policy reason for doing so. 6. Check for Custodial ProcessesThe work's processes can be fundamental or custodial. Fundamental processes are connected to the reason for the product's existencefor example, analyzing the roads, recording the weather forecasts, scheduling the trucks to treat the roads. Custodial processes exist to maintainkeep custody ofthe stored data. These processes make changes to the data solely to keep it up-to-date. These changes are not part of the fundamental processing. For example, a fundamental process for a credit card company is to record any purchases you make using its card. This is, of course, a business event that happens when you hand over the card in the store. But from time to time, you might move to a new home. When you advise the credit card company of this change of address, it uses a custodial process to update its stored data. A similar business event would occur if you changed your name or changed the card's PIN. To do this, go through the class model and the CRUD table, checking whether you have enough custodial processes to maintain all of the work's stored data. Check that where a class has changeable attributes, there is a custodial business event to change them. Repeat Until DoneStages 1 through 6 of the business event discovery process are iterative. That is, you continue to go through the processidentifying business events; modeling the business use cases; adding to the class model; checking that the classes are created, referenced, updated, and deleteduntil activity 2, "Identify business events and non-events," fails to reveal any new events. At that stage, you can be confident that there are no more business events relevant to your work. You might also investigate the automated tools at your disposal, as some of this procedure can be automated. It is not that hard to do, but if you can get some automated help, why not? |
EAN: 2147483647
Pages: 371