7. The Scope of the WorkThe first scope to be established is the scope of the work. It determines the boundaries of the business area to be studied and outlines how it fits into its environment. Once you understand the work and its constraints, you can establish the scope of the product. Keep in mind that the product has to fit seamlessly into the work, so it is appropriate to look first at the work. We suggest using a context model to describe the scope of the work and its surrounding adjacent systems. We described this model and explained how to build it in Chapter 3, Project Blastoff,
Establishing the correct work scope is crucial to the success of the product. It is worth investing all the care, and time, necessary to ensure that the context is sufficient for you to understand the parts of the customer's business that could potentially benefit from the product. Without this, your chances of producing a satisfactory product are lessened. The first two subsections, 7a and 7b, describe the work. We have looked at that topic in Chapter 3, so let us move on. 7c. Work PartitioningOnce you have established the scope of the work, it soon becomes apparent that the work is much larger than one person can comfortably understand. There is a need to partition the work into smaller, more manageable, and more convenient pieces. Business events, as we described them in Chapter 4, Event-Driven Use Cases, are the most convenient way to partition the work. Business events are things that happen in the outside worldthe outside world is represented by the adjacent systems on your context modelthat cause the work to respond in some way. Business events also happen when it is time for the work to carry out some prearranged obligation, such as producing reports, broadcasting news, or some other functionality needed to send information to the outside world.
Our projects maintain an event list showing for each business event:
If you have built any models of the response to the business event (that is, the business use case), then you put them in this section of the specification, tagged with the appropriate event number. The models can take a variety of forms: sequence diagrams, activity diagrams, data flow diagrams, and business task models, to name a few possibilities. Another option for key events is to build a business use case scenario. Chapter 6 provides details of how to do this.
|