Requirements Gathering
In this chapter you'll work through the design and development of a hypothetical band-tracking system called BandSpy. In the process you'll learn about UML diagrams and where they fit into the process.
A client from a record company has contacted you to develop a Web-based system to track the bands that client represents. During the initial phone conversation, the client explains that BandSpy should allow Web users to view details about the different bands the company represents, and check out upcoming concerts. Someone from the record company should be able to add new bands to the system, edit existing band information, and book new concert performances for the bands. Although your conversation with the client is informal, it begins a key part of the software design the requirements-gathering phase. In this phase you'll want to determine exactly what the software needs to do to satisfy its users.
Interviewing the Client
Speaking on the phone, you arrange to meet with the client. After some quality get-to-know-you time, the meeting progresses to a further discussion of the system. The attendees of the meeting are Bill, the owner of the company; Jane, the operations manager; and Tom, the company "computer guy.''
During your initial interviews, getting a feel for the roles of the people who are involved is important. You can infer that the people attending the meeting have some interest in how the software works. That interest, however, may or may not always be beneficial to the outcome of the project.
The key person to identify during requirements gathering is the person who has detailed knowledge of the domain the area that the software will model. That could include someone who previously did manually what the software will now automate, or it could be someone who knows how the business works and what the software needs to do to correctly model it. This person is often referred to as a domain expert.
Over the course of the interview, Jane does most of the talking. She describes what they're hoping the system can accomplish and how the company currently handles this process. It's a good bet that Jane is your domain expert. During further interviews, speaking to her directly will be useful. Bill stays quiet most of the time; he probably has other matters to attend to. Tom mentions that he'll be the one actually entering the data into the system. You note that you may have to devote a little time to explaining the use of the administration tools to him.
During the course of the meeting you take notes on what Jane says the system needs to do, and you come out with the following list:
-
Users can visit the BandSpy Web site and browse information about bands. Band information includes the type of band, musicians in the band, and what instruments they play.
-
Users can view information about upcoming performances that might include one or multiple bands.
-
Site administrator can add new information about bands.
-
Site administrator can edit existing band information.
-
Site administrator can add a new performance. Adding a new performance includes booking a venue and generating tickets. Separate third-party companies handle both the venue booking and the tickets. These companies have reservation systems that you will need to notify via theBandSpy software.
Now that you have a list of requirements, it's time to start putting the UML diagrams to work.
Use Case Diagrams
Use case diagrams show the system from the task-oriented perspective of a user. One use case represents a task the user is trying to accomplish with the system. Figure 2-1 shows a simple use case diagram for users visiting the BandSpy site and browsing band information.
Figure 2-1
The stick figure is called an actor and the bubble is the use case. The line indicates that this actor can perform the connected use case. In use case diagrams the actor is usually a role associated with a person, although it can represent an external system that acts upon ours.
Notice that the use case "browse band info'' is rather general. A high level of detail isn't necessary here. You just want to be able to cover all the use cases the system should be capable of. If necessary, use cases can be broken down into their separate scenarios. A scenario is the sequence of steps comprising the use case. For example, the scenario for the previous use case is as follows:
-
User goes to BandSpy Web site.
-
User navigates site using menu.
-
User examines band/musician/concert information.
The use case diagram for the administrative tasks is shown in Figure 2-2.
Figure 2-2
The administrative use cases are the separate tasks that the administrator might attempt when using the BandSpy system. The client has mentioned that he would like the administrative section of the site to require a password-protected login. Because the logging into the system can be thought of as a task itself, you can use an include to show that this use case is part of all three other use cases. Figure 2-3 shows the use of an include, indicated by a dashed line.
Figure 2-3
Multiple actors may appear within a use case diagram. Often, different actors may share a use case. Figure 2-4 shows the completed use case diagram for the BandSpy system. Because both the administrator and the regular users can look up band information, they share that use case. Additionally, the use case shows the nonhuman actor the venue booking system performing the task of updating information about an upcoming performance.
Figure 2-4
