3.13. Review: Some New Requirements
First Model the Requirement
According to our strategy, you first build stand-alone event-response models of the new requirements, and then integrate them with any existing models later. Your analysis of Sales Director Blake Hall’s requirements results in three event-response models.
The first of the three new events, Agency requires phone-in service, records an agency’s request to use the phone-in facility for a particular campaign. Figure 3.13.1 shows the system’s response to this event.
RESPONSE TYPE is the kind of service requested by the agency. Our data dictionary entry shows that the agency can request that the telephone service take orders for the product or receive requests for more information. The users must confirm if both services will ever be needed.
Since the telephone answering service does not apply to all campaigns, the people who answer the telephones may be part-time workers. If so, the system’s response may have to include a notification to whoever manages the telephone system to enable him to assemble enough staff for the expected telephone calls.
There is only one entity so we did not build a data model.
The next new event, Viewer responds to commercial, happens when the viewer makes a telephone call. Remember that Blake Hall said, “Viewers of a commercial can telephone immediately with orders or requests for more information about the product.” The system’s response to this event is to record the response details and relate them to the particular commercial spot.
Let’s start this event-response model by thinking about the data. The incoming data flow is defined like this:
Viewer Response = Product Name + Approximate Viewing Time
+ Response Type + Viewer Name + Viewer Address
In this case, building an event-response data model is particularly helpful so that you can consider how all the data will be accessed and recorded. Our data model for this event is shown in Figure 3.13.2.
Note that the response relates to the commercial spot. Blake Hall said that Piccadilly wants to be able to tell the agencies which spots attracted the responses. Because the data model portrays the business policy, it helps you to raise questions.
Once you know the data, the process model for this event is easier to build. Ours is in Figure 3.13.3.
The process model raises some questions. For instance, what happens if the viewer’s approximate viewing time does not correspond to a commercial spot for the product in question? Suppose there are two commercial spots equally close to the approximate viewing time. To which one should the response relate? Alternatively, could it relate to both spots? Our dictionary entry for VIEWER RESPONSE shows only the viewer’s name and address. Does the agency require Piccadilly to accept complete order information including credit card details?
Only the users can answer these questions. Your task is to make sure you ask all the right questions.
The last new event is temporal. It’s concerned with producing viewer response reports that are sent to the relevant agencies every morning. You will have to confirm the data in the VIEWER RESPONSE REPORT with the users, as it determines the processing for this event.
Once you model the new requirements, review them with the users, and clear them with the project manager, your next task is to integrate the new requirements.
Integrating the Requirements with Your Existing Models
Some of the new requirements to the Project are added as brand-new, stand-alone events, while other new requirements will be additions to already existing events. Let’s consider each event-response model in turn.
The agency will probably request the campaign phone-in service when it gives Piccadilly the campaign requirements. This means that you can integrate the new event Agency requires phone-in service with event 1 Agency wants to run a campaign. To add the new requirements to the event, you need to add the field RESPONSE TYPE to the flow CAMPAIGN REQUIREMENTS and to the entity ADVERTISING CAMPAIGN.
Your second new requirement, Viewer responds to commercial, is a new event. To integrate the new event into your Project, follow these steps:
• Add the terminator VIEWERS and the flow VIEWER RESPONSE to your context diagram.
• Define VIEWER RESPONSE, RESPONSE TYPE, VIEWER NAME, VIEWER ADDRESS, and ACTION TAKEN in your data dictionary.
• Add the entity RESPONSE and the relationship RESPONDING to your data model (per the event-response data model), and define them in the data dictionary.
• Write a mini specification for RECORD PHONE-IN RESPONSE.
• Add the event to your event list.
The last new requirement, Time to report viewer response to agency, is a new temporal event-response, which requires you to
• Add a data flow called VIEWER RESPONSE REPORT to your context diagram, going from the context to the terminator ADVERTISING AGENCIES.
• Define VIEWER RESPONSE REPORT in the data dictionary.
• Write a mini specification for PREPARE CAMPAIGN RESPONSE REPORT.
• Add the event to your event list.
When you have done all that, you have successfully incorporated three changes into your Project.
We have left the changes until late in the Project, but more often than not in the real world, the new requirements are mentioned early on in the analysis. Our strategy of building stand-alone models and then integrating them means that you can add new requirements on demand.
Ski Patrol
You may have taken a shortcut and modeled the first event, Agency requires phone-in service, as an alteration to event 1 Agency wants to run a campaign. We suggest you not do this because the new requirement is often an event in its own right. Also, by submerging it into an existing event-response, you may overlook some vital questions. For example, you wouldn’t think to raise the issue about notifying the staff for the telephones if you had simply altered the incoming flow for event 1.
You can identify the requirements the same way as you previously did: Draw a context diagram from the interview with Blake Hall, and use the boundary data flows to identify events. Modeling new requirements is the same as modeling existing event-responses. You have already modeled eighteen or so of them, so you are relatively experienced in this area.
If you are having problems and you skipped over it, Chapter 2.13 Modeling New Requirements would be beneficial for you to review.
Trail Guide
Easiest, 
More Difficult, and 
Most Difficult: Go to Chapter 1.15 CRUD Check to verify the integrity of your essential models.
Promenade: The others are off to do some hard work. That’s not why you are reading this book, so Chapter 2.14 New Physical Viewpoint is a good place to go next.