2.1 It's All About InteractionsClearly, 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.
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.
|