2.1 It s All About Interactions

2.1 It's All About Interactions

Clearly, the combination of artifacts produced in our projects contains a lot of information. However, it may be that they contain too much information. What if the diagrams were to concentrate on the requirements of the system from the users' perspectives? The questions is then, What do the users see?

Users view computer systems as black boxes . This term implies that the perspective of the application is concerned only with what goes in and what comes out. The inner workings are not important to the black-box perspective. Requirements documentation that puts everything in the context of "going in" and "coming out" has more relevance to the users who study it.

When we talk about "going in" and "coming out," we're talking about interactions. Interactions between the users and the computer system are what really matter in requirements gathering. For example, it is important that a user wants to enter numbers in timesheets and have the system print checks. But it is not important to the user that those timesheets go through 18 specific processes before the checks are produced. That's design. The users care only that the checks are produced and that they're right.

For an IT specialist, grasping this concept is very tough. We have strong tendencies to jump into the how before we've defined the what . We're typically advised not to get too detailed. But this is not quite accurate. The what can become very detailed. For example, the definition of printing the checks "right," in our example, could be very detailed. Information about what the system should do with calculating weekly pay based on a yearly salary, handling hourly employees , dealing with overtime, and incorporating raises at the right time can be excruciatingly detailed. However, the focus must remain on the what and not drift into the how .

Users care about what goes in and what comes out, as in a black box.

graphics/02inf06.jpg

Use cases are a tool that can show the what exclusively. DFDs, ERDs, and prototypes include what and how in their perspectives, and that can confuse users. For this reason, we recommend that use cases be the primary tool for requirements gathering.

The Origin of Use Cases

Use cases were introduced to the IT world by Ivar Jacobson (1992) and his team at Ericsson in Sweden. Their book, Object-Oriented Software Engineering took the computing industry by storm and use cases have been increasing in popularity ever since. Jacobson included use cases as part of an overall system development lifecycle methodology called Objectory , which he marketed as a product and built a company around. Later, Jacobson's Objectory company and methodology were purchased by Rational Software, and Objectory, with its use cases, became part of the Rational Unified Process (Jacobson 1999). We owe a lot to Jacobson, and this book uses many of his ideas in the definition of use cases. Before Jacobson, various ideas about stories and scenarios as requirements were introduced by Meilir Page-Jones, Rebecca Wirfs-Brock, and others. Where we can add to the ideas of these industry giants is in the practical application of use cases to solve the requirements problem. As consultants and practitioners , we have worked with use cases on the job for many years , and we understand the good and bad points of them. In this book, we have attempted to improve upon use cases, without changing them fundamentally, but instead by surrounding them with other artifacts and helpful hints to help create a more complete requirements toolset.



Use Cases. Requirements in Context
Use Cases: Requirements in Context (2nd Edition)
ISBN: 0321154983
EAN: 2147483647
Year: 2002
Pages: 90

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