Section 7. The Scope of the Work


7. The Scope of the Work

The 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,

Context models are discussed in Chapter 3, Project Blastoff, and Chapter 4, Event-Driven Use Cases.


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 Partitioning

Once 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.

For more on business event partitioning, see Chapter 4, Event-Driven Use Cases.


Our projects maintain an event list showing for each business event:

  • Event number

  • Event name

  • Input or triggering data flow

  • Output data flows

  • One-sentence summary of the event response/business use case

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.

The details of business use case scenarios are found in Chapter 6, Scenarios and Requirements.





Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net