Software Requirements Engineering
SE-203
Session 08 Student Name:
Roll/No:
Group:
A Case Study contd…
Setting Up for Requirements Gathering
The team passes the results of their meeting to the corporate bigwigs. LaHudra can't believe his good fortune in stumbling into a great new area. Nar is overwhelmed by it all. Goniff sees visions of dollar signs dancing before his eyes. They give the team the go-ahead to proceed.
Now that the team has a vision for the system, can the programmers program and the systems engineers’ engineer? Absolutely not. The team must center the WIN system around the users' needs, not around nifty technology. Although they have a few insights from the team meeting, they still haven't exposed the WIN concept to a group of employees and managers to get feedback and ideas from the users' point of view.
The next GRAPPLE action does just that. In a Joint Application Development (JAD) session, the team will gather and document system requirements. With these in hand, they will be able to make some estimates about time and money.
The JAD session takes place in a conference room. Led by a facilitator, it's called a "joint" session because it includes members of the development team along with potential system users and domain experts. The development team members in this meeting are two analysts who are doubling as note-takers, a modeler, two programmers, and a system engineer. The potential users are three servers, two chefs, two restaurateurs, and two bussers. The objective of this meeting is to produce a package diagram that shows all the major pieces of functionality for the system. Each package will represent one piece and will contain use cases that detail what the functionality piece is all about.
Let's go to the session.
The Requirements JAD Session
Facilitator: "First, I want to thank you all for coming to our session. These sessions can take a lot of time, but they can also be a lot of fun. What we're trying to do is gather the requirements for a system called WIN—Wireless Interactive Network."
"The WIN concept is pretty straightforward. The way we envision it, servers carry handheld computers and use them to communicate with the kitchen and with bussers. Bussers also carry these computers and use them for communication. The kitchen will have a desktop terminal and one or more screens. The manager will also have one in her office. Here's a picture of what I'm talking about." (See Figure 18.5.)
Figure 18.5. The WIN system.
Facilitator (continuing): "We hope to install WIN in LNG Restaurants, and we want it to help you do your jobs. In order for that to happen, we need you to tell us what you want the system to do. In other words, if the system were in place, what would you use it to do?
"We'll be asking that question over and over again. At the end of the session, we'll have an organized set of requirements that everyone will be happy with. Think of it as a high-level organized wish list. We'll use those requirements as a step toward building a blueprint that programmers will use to create the system. One thing I'd like you to keep in mind: We need insights and ideas from every one of you, no matter what your job title is."
Analyst 1: "Can we start by figuring out what the major pieces of functionality should be?"
Facilitator: "Sure can. Group, how should we proceed?"
Restaurateur 2: "Well, I wasn't in on the preliminary discussions, but I think this is a good idea. Can we organize it according to, say, areas in the restaurant? You know, the serving areas need one set of requirements, the kitchen needs another, the waiting area another, and so forth?"
Facilitator: "That's a possibility."
Analyst 2: "When I look at the business process diagrams, it seems to me we already have an organization."
Programmer 1: "What's that?"
Analyst 2: "By job. The chef has to do one set of things, the server has to do another, and so on."
Facilitator: "Sounds good. Can we agree on organizing by job?"
(All agree)
Facilitator: "All right! From the business process diagrams and the class diagrams, the jobs we have are server, chef, busser, assistant, and manager."
Restaurateur 2: "Didn't you leave out a couple? How about coat-check clerk and bartender?"
Restaurateur 1: "Ooh. How did we skip those?"
Facilitator: "I'll add those to our list, and I'll use the UML package symbols to keep track."
(See Figure 18.6.)
Figure 18.6. The packages of functionality for WIN.
Modeler: "I'm on it. I just added some information to our class diagrams. The
CoatCheckClerk class was in already. I elaborated on it and added the Bartender."
Restaurateur 2: "I wondered what you've been doing there on your laptop. Could you show us these, uh, 'classes'?"
Modeler: "Sure. Here they are." (See Figure 18.7.)
Figure 18.7. The CoatCheckClerk class and the Bartender class.
Restaurateur 2: "Interesting. Maybe when we take a break you can explain to me what it all means."
Facilitator: "Now that we have the major pieces, does anyone have a preference as to where to start?"
Server 1: "How about with the server part?"
Facilitator: "Sounds good. All right, what kinds of functionality would you want to see in this package? Remember, group, just because we're doing a piece that happens to not coincide with your particular job, you can still participate. Everyone's insights are welcome."
Server 2: "I'd like to be able to take an order on my little computer and pass it to the kitchen."
Facilitator: "Okay. What else?"
Server 1: "Can I find out the status of an order?"
Chef 2: "Can I notify a server when the order is done?"
Facilitator: "Yes and yes. You'll notice that I'm writing these in as labeled ellipses. We refer to these as use cases. We'll be asking some of you to come back and help us analyze those use cases, but that's another meeting."
The Outcome
The JAD session continued on for the rest of the day. When the participants were finished, they had a set of requirements that appear as use cases arranged in the packages.
For the Server package, the use cases were
- Take an order
- Transmit the order to the kitchen
- Change an order
- Receive notification from kitchen
- Track order status
- Notify chef about party status
- Total up a check
- Print a check
- Summon an assistant
- Summon a busser
- Take a drink order
- Transmit drink order to lounge
- Receive acknowledgment
- Receive notification from lounge
- For the Chef package, the use cases were
- Store a recipe
- Retrieve a recipe
- Notify the server
- Receive a request from the server
- Acknowledge server request
- Enter the preparation time
- Assign an order
- The use cases for the Busser were
- Receive a request from the server
- Acknowledge a request
- Signal table serviced
The use cases for the Assistant were
- Receive a request from the server
- Receive a request from the chef
- Acknowledge a request
- Notify request completed
- For the Bartender,
- Enter a drink recipe
- Retrieve a drink recipe
- Receive notification from the server
- Receive a request from the server
- Acknowledge a request
- Notify request completed
- And for the Coat-check clerk,
- Print a coat check
- Print a hat check
Figure 18.8 shows how all this looks in the UML.
Figure 18.8. The functionality package diagram.
The modeler kept evolving the class diagrams by adding the two classes and associations, as shown in Figure 18.9.
Figure 18.9. The newly added class information.
DEVELOPING THE USECASES
The use cases from the package diagram in Hour 18, "Gathering System Requirements," give a good picture of what the system will have to do. The team will have to analyze and
understand each one. They've moved gradually from understanding the domain to understanding the system. The use cases have provided the bridge. If you're getting the idea that the system development project is use case driven, you have a good understanding of the whole process.
Notice that at no point in the JAD session did the development team discuss how the system would accomplish all the activities specified in the panoply of use cases. The idea was just to enumerate all the possible use cases. As the use cases are fleshed out in this hour, notice how the components of the WIN system start to materialize. At this point in the development effort, the system begins to take center stage.
Now, put yourself in the shoes of the development team, and we'll deal with part of this collection of use cases.
The Care and Feeding of Use Cases
To analyze the use cases, you have to run another JAD session. The discussion in this JAD session is intended to derive an analysis for each use case.
A word of caution: The use case JAD session is usually the most difficult one, as it calls for the participants—potential users of the finished system—to become analysts. In their own niche, each one is a domain expert, and you have to tap into their expertise. Typically, they're not used to either verbalizing or analyzing what they know. They probably haven't been part of a system design effort before, and they may be uncomfortable trying to specify what a system should do to help them carry out their work. In order to alleviate the strain, it's best to organize the JAD session so that the team deals with one group at a time—for instance, just the servers. That way, the others won't sit idly by as the servers analyze their use cases. The overall domain experts, the restaurateurs, can show up to lend a hand with all the groups. A cross-section of the users would be appropriate when dealing with the Customer package.
The use cases are numerous. Just to keep this hour manageable, we'll focus on the first eight use cases for the Server package. After you see how these analyses are done, you'll be able to deal with the remaining Server use cases, as well as the use cases for the other packages, on your own. (See the exercises in the Workshop at the end of this hour.)
The Use Case Analysis
Remember that each use case is a collection of scenarios, and each scenario is a sequence of steps. For each scenario in each use case, you'll want to show A brief description of the scenario Assumptions for the scenario. The actor who initiates the use case
Preconditions for the use case System-related steps in the scenario
Postconditions when the scenario is complete
The actor who benefits from the use case (In your analysis, you can also include any exception conditions or alternative flows. I've kept the scenarios simple for this example, however.)
No specific way of laying out a use case analysis is correct. The items listed typically provide a complete picture of a use case.
In your design document (the document you give your client and the programmers), each of these use case analyses will have a separate page. You'll probably want to include a diagram of the use case, complete with actors, on this page.
The system-related steps in the scenario are extremely important. They'll show how the
system is supposed to work. When the JAD session participants tell you these steps, they're describing, in effect, what the system will ultimately look like. After this JAD session, you should have a good idea about the components of the system.
The assumptions are important, too. In the list of assumptions, you can list design considerations, as you'll see.
This is what I meant by the system development project being use case driven. The use cases will ultimately create the path to the system.
The Server Package
The Server class seems to figure in the greatest amount of activity. This isn't surprising because the Server interacts with virtually every other class.
The Server use cases are
- Take an order
- Transmit the order to the kitchen
- Change an order
- Track order status
- Notify chef about party status
- Total up a check
- Print a check
- Summon an assistant
- Summon a busser
- Take a drink order
- Transmit a drink order to lounge
- Receive acknowledgment
- Receive notification from lounge
- Receive notification from kitchen
Take an Order
Let's begin with "Take an order." The team relies on experienced servers for a description, assumptions, preconditions, steps, and postconditions. The package and subpackage already indicate the initiating actor (Server) and the benefiting actor (Customer). A good one-sentence description might be, "The server enters the customer's order into the handheld device and transmits it to the kitchen." The assumptions are that a customer wants a meal, the customer has read the menu, and the customer has made a selection. Another assumption is that the server's handheld has a user interface dedicated to order entry.
The preconditions are that the customer has been seated and has read the menu. The
Postcondition is that the order is entered into WIN.
The steps in the use case are
On the handheld computer, the server activates the user interface for order entry.
The order-entry user interface appears. The server enters the customer's menu selection into WIN.
Although the assumption is that an order entry interface exists, you haven't yet specified how that interface will look or how the physical act of entering the order will proceed. You don't know yet what the kitchen PC's user interface will look like, nor have you said anything about the technical details of transmitting an order.
The point is that as you state your design assumptions, you're starting to get a handle on what the system is supposed to do, and you'll start to crystallize your thoughts on how to do it. The steps in the use cases force you to come up with assumptions about the components of the system. Remember that the use cases are intended to show how the system looks to a user.
Transmit the Order to the Kitchen
Ready for another? This one will be included in (that is, used by) at least two use cases—the previous one and "Change an order."
The description is, "Take an order entered into the handheld, put it on the wireless network, and send it to the kitchen PC." The assumptions are that you'll have a means of communicating the order (via a wireless network), and again, that you have an order-entry interface. Do you have to repeat this assumption? You do. Each use case will eventually appear on a separate page in the design document, which will serve as a reference about the system. For clarity, the assumptions should appear on each use case, even if you have to repeat them from use case to use case.
The precondition is an order entered into a handheld. The post condition is that the order has arrived in the kitchen. The benefiting actor is the customer.
The steps are A button-click in the order-user interface indicates "Send to kitchen."
1. WIN transmits the order over the wireless LAN.
2. The order arrives in the kitchen.
3. The order-entry user interface on the handheld indicates that the order arrived in the kitchen.
4. Obviously, you have to change your use case diagram for the customer subpackage. It has to show the «include» dependency between this use case and "Take an order" and between this use case and "Change an order." Figure 19.1 shows the updated use case diagrams for the Server package.
Figure 19.1. The updated use case diagrams for the Server package.
Change an Order
While we're on the subject, let's move to "Change an order." The description is, "Modify an order already entered into WIN." The assumption is that an order has already been placed and sent to the kitchen and that, subsequently, the customer wants to change that order. You also assume that WIN has a database of orders showing the server who entered each order and the table the order came from, that the server can access the database from the handheld, that WIN can make transmissions from the handheld to the kitchen PC and back, and that the handheld has a user interface screen for changing an order. The precondition is the previously placed order. The postcondition is that the modified order has arrived in the kitchen. The benefiting actor is the customer.