The Approach

In the previous chapter we discussed the benefits gained by the database team being involved in business modeling along with the application development team. Those same benefits are still valid during the development of the system use case model. However, now those same benefits are extended to the developers. Often developers (and database designers) have no knowledge of the business for which they build software systems. Since the information from the business models is used to “preload?the system use case model and other subsequent models, the team members can now begin to understand the business context in which their system is intended to operate.

If you look at the many studies published on the failure of development projects, you will see that, invariably, in the top 10 reasons for failure are two items:

• Misunderstanding the user's needs—  this includes the user not participating in the development, the developer ignoring the user's input, vague user needs, and so on.

• Misunderstanding the system requirements—  this includes vague, non existent, incorrect, missing, and changing requirements.

Being involved in the requirements definition can only help reduce the risk on your development project. Also, errors caught at this early stage of development are much less costly (in both time and money) to fix than those found during system testing.

Involving the Database Team

The venue for much of the requirements definition phase will likely be somewhat different than that for business modeling even though the team will be dealing with many of the same artifacts. Much of the work in this phase is translation and structuring—prime areas for system and data architects. The level of participation by the business people now will typically begin to wane slightly. This is simply because of the nature of the tasks.

Let's look at the “translation?tasks. The abundance of model elements discovered during business modeling must be brought into the system use case model. This is primarily an architectural task, not a business task. The first cut at this process can be very straightforward since many of the same elements just come directly from the business to the use case model. For example, some possible transformations, suggested by the Rational Unified Process, are listed in Table 4-1.

Of course, these are potential initial transformations that can easily change as analysis proceeds. Automating an entire function can eliminate a business worker; thus, a business worker could become a use case. For example, the function of a typical salesperson (a business worker) in a brick-and-mortar retail store can be Web-enabled. Thus, some of the functions that were performed by that salesperson can be shared between the Online Client (a business actor) and an Online Sale use case. Note that business entities were not forgotten in Table 4-1. They will appear as entity classes, not in the use case model but subsequently in the analysis and/or design models.

Table?-1. Business Model to System Use Case Model Transformation

In the Business Model	?/font>	In the Use Case Model
Business use cases	become	Subsystems
Business actors	become	Actors
Business workers	become	Actors or use cases
Business workers' activities	become	Use cases

Once these initial translations are made, the business people play a very important role as validators and elaborators. When the architects decided to automate that business worker in the previous example, was the manner in which that split was done consistent with how the business people want the business to operate? The business people must validate these types of functional adaptations that the development team chooses to make. Also, definition of additional system use cases needed to realize the business model must be done with the agreement of the business people. At this point, regular sessions with the business people will prove valuable since they will be able to elaborate the interactions between the system use cases and the actors.

One effective way to utilize the business people during this period is to familiarize them with the use case description templates you will use to elaborate the detailed flow of the use case. Once comfortable with the format, there is nobody who can better elaborate what the use cases should do than the business people. Often we have found that, given a little mentoring on use case development and the templates, the business folks are willing to define the flows of the use cases. This increases the quality of the use case definitions and helps avoid the introduction of “translation?errors, which can occur if the development team defines the use cases on its own.

Database Designer As these transformations occur and new actors and use cases are created, remember that, just as in the business modeling phase, these likely will become entities (for example, actors) in your data model or will generate additional entities (as new use case descriptions and/or sequence diagrams are updated or newly created). This will allow you to further refine your conceptual data model.

One warning: be very careful when developing the use case model. If you use the “extends?or “includes?stereotypes in your modeling, avoid falling into functional decomposition. Use cases are not comprised of multiple lower-level use cases. A business use case may be “realized?by numerous system use cases, but it does not decompose into these system use cases, nor should the system use cases be decomposed into smaller use cases. Remember, each use case is a complete flow of events that produces a result of value to the actor. If you decompose a use case you break the “completeness?of the use case. For example, if you have a use case, Withdraw Cash, for an automatic teller machine, this use case does not decompose into Insert Card, Enter PIN, Select Account, and similar use cases. Each of these individually is not a complete flow nor does each individually provide value to the actor.

Database Designer What may be the most valuable aspect of requirements definition and its use case modeling for the database designer is ensuring correct concepts. Most companies do not throw away their databases. However, applications are regularly significantly modified or even discarded. What is the probability that the newly hired developer on your project will correctly understand the context and structure of your existing database's Account table? Can it really be accessed by that attribute/column? Does it even have that column? Or will she just make the assumption that accounts are accounts and proceed to use the account abstraction as she sees fit in the system design? If you don't find this out early in the development, how much “damage?will this cause later to your database design when you have to make a last-minute change to the database to fix this misunderstanding? Everyone must understand and agree to these critical definitions before significant time and effort are expended to solidify possibly erroneous concepts deep in the application design. The database designer is in a key position to ensure these critical concepts are correctly captured and understood.

Table?-2. Business Use Case Prioritization

Business Use Case	Priority	Which Delivery/Iteration
Comply with Regulations	High	First
Manage Clinical Records	High	First
Provide Clinical Care	High	First
Respond to Inquiry	Med	Second
Accounts Receivable	Low	Second