Use Cases and Their Scope


The term use case was coined by Ivar Jacobson to describe an amount of work to be done. He chose to break the system into smaller units, as he felt that object models were not scalable. Thus, to conquer the complexity and largeness of modern systems, Jacobson said it was first necessary to partition them into convenient chunks, and that these chunks should be based on the user's view of the system.

Jacobson, Ivar, et al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.


However, Jacobson leaves us with some loose ends. For example, his definition of a use case does not indicate precisely where or how a use case starts and ends. In fact, Jacobson's definition of a use case must have left some ambiguity. Others have written about use casesin fact, more than 40 published definitions of "use case" exist and, predictably, few of them agree. This chaos is unfortunate. Jacobson also uses the term actor to mean a user role, or perhaps another system, that lies outside the scope of the system. The system in this usage is presumed to be the automated system. This point leads to a question: How can we know the automated system before we understand the work for which it is to be used?

If the responsibilities of the actor and the system are established at the beginning of the analysis process, and the requirements gathering focuses on the automated system, how will we ever understand the work the actor is doing or the work the automated product could be doing for the actor?


Think about this: If the responsibilities of the actor and the system are established at the beginning of the analysis process, and the requirements gathering focuses on the automated system, how could you ever understand the work the actor is doing, or the work the automated product might be doing for the actor? Without understanding the actor's true taskwhich surely happens if you exclude the actor from the analysis studyyou run the risk of missing opportunities for automation or automating where a non-automation would be a better solution. You also could be guilty of building products that are not as useful as they might be as well as running the risk of constructing interfaces that ultimately do not satisfy the user.

So let us instead first establish the scope of the work. This work scope must include the intended actors and the work they are doing. Once you have established a satisfactory scope for the work, you will partition it into smaller pieces. These pieces are the use casesboth business use cases and product use cases.

Let's look at how to handle this task. Keep in mind that it probably takes longer to describe each of the steps than it does to actually complete most of them.




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